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PREFACE 


The iRMX 86 Operating System is a software package that provides a 
realtime, multitasking environment for Intel iAPX 86-based 
microcomputers, including the iSBC 86/12A single board computer. This 
manual contains the instructions that you need to configure an iRMX 86 
application system using Release 3.0 of the iRMX 86 Operating System. By 
following the instructions in this manual, you can use an INTELLEC Series 
II or Series III Microcomputer Development System to build an iRMX 86 
system. 


READER LEVEL 

This manual assumes that you are a system programmer, experienced in 
dealing with operating systems. In particular, it assumes you are 
familiar with the following: 

• The iRMX 86 Operating System and the iRMX 86 reference manuals 

• The 8086/8087/8088 Macro Assembly Language and/or PL/M-86 

• The INTELLEC Series II or Series III Microcomputer Development 
System 

• LINK86 and LOC86 


• The notions of segments, groups, and classes as they apply to 
assembly language, PL/M-86, LINK86, and LOC86 


NOTATIONAL CONVENTIONS 


The following conventions are used to show syntax in this manual: 

UPPERCASE Information appearing in uppercase must be entered or 
coded exactly as shown. This information, however, can 
actually be entered in uppercase or lowercase. 

lowercase Fields appearing in lowercase indicate variable 

information. The user must enter the appropriate value or 
symbol for variable fields. 
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CHAPTER 1. INTRODUCTION 


The Intel iRMX 86 Operating System is a software package designed for use 
with the Intel lAPX 86,88-based microcomputers. It is a powerful and 
flexible system around which you can build your application system. 

The iRMX 86 Operating System consists of a number of subsystems, some of 
which must be included in your application system, and some of which are 
optional. The subsystems of the IRMX 86 Operating System are: 

• Nucleus This is the core of the iRMX 86 Operating 

System and is required by every application 
system. It provides services for the remainder 
of the software running in the system. 

• Terminal Handler This is an optional subsystem that provides a 

real-time interface between your terminal and 
other software running under the supervision of 
the Nucleus. 

• Debugger This is an optional subsystem that provides a 

facility for debugging and monitoring software 
running under the supervision of the Nucleus. 

• ^/Q System This is an optional subsystem that provides 

asynchronous file access capabilities for 
software running under the supervision of the 
Nucleus . 

• Extended I/O This is an optional subsystem that provides high 

System level, synchronous file access capabilities for 

software running under the supervision of the 
Nucleus. 

This is an optional subsystem that provides the 
capability to load object files into memory 
from disk under the control of the Operating 
System. 

• Bootstrap Loader This is an optional subsystem that provides the 

capability to load the other subsystems and/or 
application jobs into memory from disk and 
begin system execution. 

• Human Interface This is an optional subsystem that provides an 

interactive interface between a user and 
software running under the supervision of the 
Nucleus. 
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INTRODUCTION 


Software that you create runs In an IRMX 86 application system using the 
facilities of the Nucleus and the other subsystems. 

Configuration consists of selecting the subsystems that are appropriate 
for your system, tailoring them to meet your individual needs, and 
combining them with your own application software to form a functional 
application system. Figure 1-1 illustrates this. 


PARTS OF iRMX 86 
OPERATING SYSTEM 



Figure 1-1. IRMX™ 86 Application System 
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INTRODUCTION 


CONFIGURATION ENVIRONMENT 

The INTELLEC Microcomputer Development System provides the environment in 
which you create your application system. With the development system 
you can code and translate your user software, and link and locate the 
various components of the application system. Upon completion, you can 
load your iRMX 86 application system from the INTELLEC development system 
into an iAPX 86,88-based microcomputer using the ICE-86 in-circuit 
emulator, or the iSBC 957A/B package. 

The development system can also be used to run the Files Utility 
(described in the IRMX 86 INSTALLATION GUIDE ). The Files Utility can 
format iRMX 86 disks and copy your system onto disk. Then you can use 
the Bootstrap Loader to load your system. 


TASKS, JOBS, AND THE INITIAL SYSTEM 


Tasks are the active parts of an iRMX 86 application system. The 
subsystems contain tasks that perform some of the functions of the 
Operating System. Your application software also consists of one or more 
tasks. Each task is part of a job. A job is the environment in which 
tasks run; thus a job consists of tasks and the resources that they use. 
The iRMX 86 NUCLEUS REFERENCE MANUAL describes this in detail. 

The jobs in a system form a hierarchy. A task in one job can create 
other jobs. Tasks in the new jobs can create still other jobs, and so 
forth. The jobs which contain tasks that create other jobs are called 
parent jobs , and the jobs they create are their offspring . 

Task and job creation is a dynamic process. However, when you configure 
a system, you specify an Initial system which is created automatically 
when the system starts executing. The job tree for an initial system 
consists of an ultimate parent job called the root job and a number of 
its offspring called first -"level jobs . Intel supplies the root job. 

Some of the first-level jobs are jobs for the subsystems that your 
application system requires (the Debugger, the Terminal Handler, the I/O 
System, the Extended I/O System, the Application Loader, and/or the Human 
Interface). Intel also supplies these jobs as part of the subsystems. 

The remainder of the first-level jobs are jobs that you provide. Figure 
1-2 illustrates an Initial job tree. 
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Figure 1-2. Initial Job Tree 


First-level jobs can spawn a number of offspring jobs, beginning the 
dynamic tree structure of the system. The IRMX 86 NUCLEUS REFERENCE 
MANUAL describes how to create new tasks and jobs. However, in order to 
create all of its offspring jobs, a first-level job must be able to 
determine where in memory the code for all of its offspring tasks 
resides. You provide this ability in one of two ways: 

o The easiest and most common way is by linking a first-level job 
and all of its offspring jobs together in one link module. This 
allows tasks in the first-level job to use symbolic names to 
specify the start addresses and data segment bases in calls to 
CREATE$JOB. 

o If the code is too large to link together in one module, you can 
link and locate the tasks separately. However, this prevents 
some tasks from referring to other tasks with symbolic names. In 
this case, when a task in the first-level job creates offspring 
jobs or tasks, it must specify absolute values for the start 
address and data segment base parameters of CREATE$JOB or 
CREATE$TASK. 

You must use one of these methods for each first-level job that you 
create* Chapter 4 contains a further description. When you configure a 
system, you must supply information to the root job about each 
first-level job. 
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TYPES OF SYSTEM CONFIGURATION 


When you define an IRMX 86 configuration, you may have one of several 
goals in mind* You may be putting together your first iRMX 86 system and 
thus want to test and debug the entire system* You may have gotten 
portions of the system working to your satisfaction, but now want to 
correct a few isolated bugs or add a new task or tasks* Or, you may have 
completely tested and debugged your system and now want to create the 
final ROM-based version* 

When building your first system, you should locate your entire system in 
RAM only* This saves you the trouble of burning code into PROM, only to 
have to reburn it later* 

When creating your final system, you must perform additional procedures 
because you are locating the system in two different areas of memory, ROM 
and RAM. In a ROM/RAM system, you must separate all of the ROM-resident 
parts of the system and locate them in ROM. 

When building an intermediate system, you have debugged and tested 
portions of your system, but are still developing or debugging others* 

In this case you have two options* Each time you make a correction you 
can use the same initial RAM-only configuration, and reload the entire 

system into RAM for testing* Or, you can follow the procedures for 

locating a ROM/RAM system for the stable portions of your system only, 
such as the Nucleus* If you burn the stable portions into PROM, you save 

the time of loading each time you generate a new system* 


USING THIS MANUAL 


Chapter 2 of this manual lists the procedure Involved in building an 
iRMX 86-based system in step-by-step instructions. You can read Chapter 
2 first as an overview and then use it later as an easy reference. 

Chapter 3 and Chapters 6 through 13 discuss creating your application 
jobs and selecting features of the subsystems that you want to include in 
your application system* You should read Chapters 3 and 6 and some or 
all of Chapters 7 through 13, depending on which subsystems you are 
including in your application system* 

Chapter 4 describes locating a test system in RAM. Use it when you are 
building your first system* It also contains step-by-step instructions, 
but in much more detail than in Chapter 2. 

Chapter 5 describes the modification you must make to your RAM configur- 
ation in order to make it a ROM/RAM configuration* Use it in conjunction 
with Chapter 4 to create either an intermediate or final system* 

Appendix A contains a sample configuration session for a RAM-based system* 

Appendix B describes the process of burning the Nucleus code into PROM. 

Appendix C lists the system call requirements of each of the optional 
subsystems. 
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CHAPTER 2. PROCEDURAL OVERVIEW 


The process of defining and building an iRMX 86 application systen 
involves a number of steps. The following overview illustrates the main 
points and refers you to appropriate sections of this manual for detailed 
descriptions . 

!• Build and generate a configuration file for each subsystem that 
you are going to include in your system. Refer to Chapter 6 for 
a discussion of the Nucleus, Chapter 7 for the Terminal Handler, 
Chapter 8 for the Debugger, Chapter 9 for the Basic I/O System, 
Chapter 10 for the Application Loader, Chapter 11 for the 
Bootstrap Loader, Chapter 12 for the Extended I/O System, and 
Chapter 13 for the Human Interface. 

2. Write code for and compile all application jobs that you want to 
be a part of the application system. Refer to Chapter 3 for 
further information. 

3. Prepare the memory map for your system. Refer to the "General 
System Layout** section of Chapter 4 for further information. 

4. Iteratively link and locate each subsystem and first-level 
application job in your application system. Record the pertinent 
information on the memory map. Refer to the *'Iterative Link and 
Locate Process** section of Chapter 4 for further information. 

5. Build a configuration file containing a %J0B macro for each 
subsystem and first-level application job, one or more %SAB 
macros, and one %SYSTEM macro. Refer to the *’Build The 
Configuration File** section of Chapter 4 for further information. 

6. Assemble the configuration file and link and locate the root 
job. Refer to the "Generate The Root Job" section of Chapter 4 
for further information. 

7. Using the ICE-86 in-circuit emulator or the ISBC 957A/B package, 
load the system into RAM. Refer to the "Load and Test The 
System" section of Chapter 4 for further information. 

8. Test and debug the system in RAM. Refer to the "Load And Test 
The System’* section of Chapter 4 for further information. 

9. Lay out a ROM/RAM system, but load it into RAM for testing. 

Refer to Chapter 5 for further information. 

10. Load the final system into ROM/RAM. Refer to Chapter 5 for 
further information. 
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CHAPTER 3. PREPARING JOBS FOR SYSTEM CONFIGURATION 


Building a system involves linking and locating each job in the iRMX 86 
application system and providing the root job with Information concerning 
the first-level jobs. Before you begin this process, you must make sure 
that the pieces of the system, the Intel-supplied jobs and your user 
jobs, are ready to be combined. This involves the following of two 
operations . 

• Preparing application jobs 

• Preparing the subsystems 

When you begin the configuration process, you do not need to have all the 
jobs in your system written, because configuration can be an iterative 
process. That is, you can build your initial system with only one 
application job, and test it, before adding more jobs into the system. 

In this way you can build on a stable system. Or, if all your 
application jobs are available, you can build your initial system with 
all of your application jobs present, and test and debug the entire 
system at once. Regardless of how you build your application system, the 
information provided in this chapter allows you to integrate jobs easily 
into the iRMX 86 environment. 


PREPARING APPLICATION JOBS 


You can write the code for your application tasks in either PL/M-86 or 
assembly language. This manual assumes that you are using PL/M-86. In 
order to use assembly language, you must use version 3.0 of the 
8086/8087/8088 Macro Assembly Language and adhere to the PL/M-86 calling 
conventions. These are described in the appropriate 8086/8087/8088 MACRO 
ASSEMBLER OPERATING INSTRUCTIONS manual. The iRMX 86 PROGRAMMING 
TECHNIQUES manual also contains information to help you write assembly 
language tasks. 

If you have any problems using the PL/M-86 language or compiling PL/M-86 
code, refer to the appropriate PL/M-86 manual, either the PL/M-86 
PROGRAMMING MANUAL FOR 8080/8 085-BASED DEVELOPMENT SYSTEMS, the PL/M-86 
COMPILER OPERATING INSTRUCTIONS FOR 8085-BASED DEVELOPMENT SYSTEMS, or 
the PL/M-86 USER’S GUIDE FOR 8086-BASED DEVELOPMENT SYSTEMS. However, in 
order to make use of the features of the iRMX 86 Operating System, you 
must follow instructions additional to those provided in the PL/M-86 
manuals when writing your code. The following sections provide this 
information. 
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LANGUAGE REQUIREMENTS 

Note the following language requirements when writing your task code: 

• Designate all of your tasks as procedures • Do not use main 
modules In your application system* 

• If you are compiling your PL/M-86 code using any model other than 
large, specify the ROM compiler control. This causes the 
compiler to place the CONST segment In the CODE class, where It 
can be more easily loaded Into ROM. You do not need to specify 
the ROM control for those programs compiled using the large 
model, because the compiler automatically does this for the large 
model. 

• Be careful of using the DATA and INITIAL statements. The DATA 
statement Is valid only If you are using the PL/M-86 large model 
of computation or If you specify the ROM compiler control. The 
INITIAL statement cannot be used In a procedure If you are going 
to place that procedure In ROM. It can be used, however. If you 
are going to use the Bootstrap Loader or the Application Loader 
to load the procedure. 


INCLUDE FILES 

There are a number of files contained on the IRMX 86 release diskettes 
that can be Included with your PL/M-86 procedures at compilation time. 

You must Include some or all of these files, depending on the subsystems 
your programs make use of. Table 3-1 lists these files according to type 
and subsystem. You must Include the files In the compilation of your 
procedures If those procedures use the system calls of the associated 
subsystems. For example. If your procedures make Nucleus and I/O System 
system calls, then you must Include the four files associated with those 
subsystems In the compilation of your procedures. 

The INCLUDE files with the extension EXT contain the external PL/M-86 
declarations that procedures need In order to use the system calls of the 
associated subsystems. You can copy these files, edit them, and 
eliminate the external declarations for system calls that you do not use 
In your procedures. This can prevent dynamic storage overflow In the 
compiler. Refer to the IRMX 86 PROGRAMMING TECHNIQUES MANUAL for further 
Information. 

The INCLUDE files with the extension LIT contain the PL/M-86 declarations 
and assignments for the subsystem condition codes. 

To Include the necessary files In the compilation of your procedures, use 
the PL/M-86 $INCLUDE control. Both the PL/M-86 COMPILER OPERATING 
INSTRUCTIONS FOR 8080/8085-BASED DEVELOPMENT SYSTEMS and the PL/M-86 
USER'S GUIDE FOR 8086-BASED DEVELOPMENT SYSTEMS describe this control. 
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Table 3-1. INCLUDE Files 


SUBSYSTEM 

EXTERNAL DECLARATIONS 
FILE 

CONDITION CODE 
FILE 

Nucleus 

NUCLUS.EXT 

NEXCEP.LIT 

I/O System 

lOS.EXT 

lEXCEP.LIT 

Application loader 

LOADER. EXT 

LEXCEP.LIT 

Extended I/O System 

EIOS.EXT 

EEXCEP.LIT 

Human Interface 

HI. EXT 



SIZE CONTROL CONSIDERATIONS 

Part of the configuration process requires selectively locating various 
modules of the system (as described in Chapter 4). When you use class 
names on segment declarations you simplify this procedure. The PL/M-86 
compiler provides standard class designators for various segments of a 
program module. However, when writing your application code, be aware 
that the assignment of segments, classes, and groups in the PL/M-86 
output module varies according to the size control specified with the 
PL/M-86 compiler call. (Refer to the PL/M-86 COMPILER OPERATING 
INSTRUCTIONS FOR 8080/8085-BASED DEVELOPMENT SYSTEMS or the PL/M-86 
USER'S GUIDE FOR 8086-BASED DEVELOPMENT SYSTEMS for details.) 

The size control of the PL/M-86 compiler call also determines how certain 
registers are initialized. The next chapter discusses this in detail. 

It is recommended that you use the same PL/M-86 size control for all of 
your PL/M-86 jobs, and that any assembly language modules be compatible 
with this control. 


INITIALIZATION 

When you configure an application system, you specify an initial system 
consisting of a root job and several first-level jobs. When the system 
starts executing, the Nucleus creates the root job. A task in the root 
job, the root task, then creates each of the first-level jobs. Tasks in 
the first-level jobs create the remainder of the application system. 
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When created, each first-level job contains only a single task. That 
single task creates or starts the creation of all other objects required 
by the first-level job. Thus It is referred to as th^ Initialization 
task for its job, even though It may perform other functions as well. It 
is ln 5 )ortant for you to synchronize the operation of each Initialization 
task with that of the root task to ensure proper functioning of your 
application system. 

The root task is structured so that it creates the first-level jobs one 
at a time. It contains a programming loop that in general performs the 
following: 

Repeat for each first-level job 

1. Create first-level job 

2. Suspend root task (until resumed by a first-level job) 

Until finished 

End 

Each time the root task creates a first-level job, the root task suspends 
Itself to allow the Initialization task in the new job to perform 
synchronous Initialization. Synchronous initialization consists of 
functions that must be performed immediately, before some other 
first-level job is created. Typically, this requires creating objects or 
making resources available that tasks in first-level jobs not yet created 
expect to be available when they themselves are created. (For example, 
the Initialization task in the I/O System job must create the entire I/O 
System before it can allow the root task to create other first-level jobs 
that might make use of I/O System functions.) 

When the Initialization task finishes its synchronous initialization, it 
must Inform the root task that it is finished, so that the root task can 
resume execution and create another first-level job. The initialization 
task must always inform the root task that it has completed its 
synchronous initialization process by making the following procedure call: 

CALL RQ$END$INIT$TASK; 

This procedure call is not described in any other manual. It requires no 
parameters. When you call this procedure, the root task resumes 
execution, allowing it to create the next first-level job. You must 
Include a call to RQ$END$INIT$TASK in the Initialization task of each of 
your first-level jobs, even if the jobs require no synchronous 
Initialization. If one of the first-level tasks does not include this 
call, the root job remains suspended and cannot create any of the 
remaining first-level jobs. File NUCLUS.EXT contains the external 
declaration for this RQ$END$INIT$TASK and the Nucleus Interface library 
(described in Chapter 4) contains its code. 
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The amount of synchronous initialization that an initialization task must 
do depends on your job structure* You may require some of your 
initialization tasks to create all of the offspring jobs and a number of 
other objects before calling RQ$END$INIT$TASK. Some others may only have 
to perform one or two functions, call RQ$END$INIT$TASK, and then resume 
the process of initialization asynchronously. Still other Initialization 
tasks may not have any synchronous initialization requirements and so can 
call RQ$END$INIT$TASK before performing any initialization. You must 
determine how the pieces of your system interact, and how they must be 
synchronized. 

Another important factor in initialization is the order in which the root 
job creates the first-level jobs. The amount of processing your 
initialization tasks must do before calling RQ$END$INIT$TASK may depend 
on which jobs the root task has already created and which jobs it has yet 
to create. The order in which the root task creates first-level jobs 
depends on the order that you specify these jobs in a configuration file, 
not on the priority of the tasks in those jobs. (Refer to the 
description of the %JOB macro in Chapter 4.) Always specify the %JOB 
calls for the subsystems first, so that they are created and initialized 
first and are available to all other jobs. The order in which you 
specify your other first-level jobs depends on your application system. 

You should always use RQ$END$INIT$TASK as described in this section in 
order to perform your synchronous initialization. Do not attempt to 
accomplish the same function by temporarily ralsiing and lowering task 
priorities. The iRMX 86 Operating System does not guarantee that your 
tasks will execute in the correct order if you use priorities to 
determine initialization order. 


PREPARING THE SUBSYSTEMS 

The subsystems have been created in a manner that allows you to choose 
system calls and features that you want to have available in your 
system. To prepare them, you must create tables that select or omit 
features. You must create these tables in a format understandable to the 
8086/8087/8088 Macro Assembler, assemble them, and link them to the 
subsystems. The details of preparing individual subsystems are contained 
in Chapters 6 through 11. 
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After you have prepared your application jobs and the subsystems, you 
should locate your first system entirely in RAM to facilitate testing and 
debugging of your programs* It is much easier to test and debug your 
programs in RAM than it is to continually reburn your PROMs when you 
detect errors. After debugging in RAM, you can locate the final system 
in ROM/RAM or copy it to a secondary storage device and load it with the 
Bootstrap Loader. 

Putting together a RAM-based system consists of the following steps: 

1. Laying out the system 

2. Linking and locating the Nucleus and application jobs 

3. Building the configuration file 

4. Generating the root job 

5. Loading and testing the system 

If you wish, the linking and locating can be separate steps. That is, 
you can use LINK86 to link any or all of your subsystems and jobs before 
ever starting the locate process. However, because the release diskettes 
for each subsystem contain SUBMIT files that link and locate the 
subsystems in one step, this manual considers the link and locate 
processes together. The following sections discuss the steps in more 
detail. 


GENERAL SYSTEM LAYOUT 

Linking and locating a system is an iterative process. That is, you must 
link and locate one first-level job and the offspring jobs, examine the 
locate maps to determine the ending address, and use that Information to 
link and locate the next first-level job and offspring jobs. Therefore, 
before you use LINK86 to link the pieces of your system together and 
LOC86 to assign absolute memory addresses, you must decide where in 
memory to start locating the pieces, and in which order to locate them. 
The following sections discuss the various factors that you must consider 
when laying out your system. 
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NOTE 

This manual assumes that you link each 
first-level job together with its 
offspring jobs to produce a single link 
module, referred to as the first-level 
job, which you then locate at an 
absolute address* If you do not link 
your jobs together, you should follow 
the same locate procedure outlined in 
this chapter, but locate every job, not 
just the first-level jobs. 


SYSTEM TYPE 

At first, when creating an initial test system, you should locate all of 
your modules in RAM. This allows you to lay out the system on a 
job-by-job basis. You can locate all segments associated with one job 
(code segments, data segments, etc.) sequentially in RAM and locate all 
segments of the next job following the first. 

Later, if you locate a final ROM/RAM system, you must locate the system 
by class, not by job. You must locate the code classes from all of the 
jobs at ROM addresses, and the data, stack, and memoiry classes at RAM 
addresses. Chapter 5 describes locating a ROM/RAM system. For now, 
however, lay out your system on a job-by-job basis, totally in RAM. 


HIGH AND LOW LOCATION OF MODULES 

You can locate the system either high or low in memory. When locating 
high in memory, assign the first module to the numerically largest 
absolute memory locations and the succeeding modules to numerically 
smaller locations. When locating low in memory, assign the first module 
to the numerically smallest memory locations and the succeeding modules 
to numerically larger locations. This manual assumes low location of 
modules because it is the easiest method to use with the iterative link 
and locate process that this chapter describes. 


MODULE ORDER 

The order in which you lay out your modules in memory should depend on 
the relative stability of the modules. You must later create a system 
configuration file that contains addresses of various parts of your 
system. If you can keep the stable portions of your system located at 
constant addresses, you can minimize modifications to the system 
configuration file. 
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Although you can change the sizes of the Nucleus and the subsystems by 
reconfiguring them, it is likely that their sizes will remain constant 
during your development cycle. Therefore, locate these modules first. 
Locate any of your application jobs that are subject to change later in 
memory, so that their size fluctuations do not necessitate changing the 
addresses of the other modules. In general, lay out your system as shown 
in Figure 4-1. 




APPLICATION FIRST-LEVEL 
JOBS 


ROOT JOB 


OPTIONAL SUBSYSTEM 
FIRST-LEVEL JOBS 


NUCLEUS 


LOW RAM ADDRESSES 


Figure 4-1. General System Layout 


Notice that Figure 4-1 illustrates locating the root job. Later sections 
of this chapter discuss the root job. For now, just note its position in 
the system layout. 

As you continue to test and debug your system, you may wish to create a 
fairly stable system with just a few user jobs and use that system as a 
base on which to build, testing and debugging each new job you add before 
adding others. If so, use the layout shown in Figure 4-1 for your first 
system and locate any new jobs you add at the end, where there is space 
available for them to grow during the debugging period. 


PREPARING A MEMORY MAP 

After you have decided in general how to lay out your system, prepare a 
memory map to Indicate this. Figure 4-2 is a worksheet that you can use 
for this. To prepare a memory map, do the following: 
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1. In the right column of the worksheet, record the highest RAM 
address in y4ur system. Notice that addresses corresponding to 
the beginning and end of the Interrupt vector and reset vector 
have already been recorded. The locations 40:0 through 6F;F are 
reserved for the iSBC 957A monitor and the locations 40:0 through 
7F:F are reserved for the ISBC 957B monitor. The locations 80:0 
through FF:F (marked free space on the worksheet) are reserved 
for future use and locations 100:0 through 103:F are reserved for 
wake-up addresses. The wake-up address space reserved allows 
room for four one page wake-up address areas. The first of these 
is used by the default ISBC 215/220 configuration and maps to its 
default base port address of 100. Adhering to these 
recommendations for reserved addresses allows you to use the 
default addresses supported by the IIUIX 86 Basic I/O subsystem. 

2. In the center column of the worksheet, list the modules In the 
order you wish to locate them, one to a line, with the first 
module (the Nucleus) closest to the bottom of the worksheet. 

3. In the right column, on the same line as the first module, record 
the lowest available RAM address. Use this value when locating 
the first module. 

After you have made this map, use it during the link and locate procedure 
to condense the Important Information from the locate maps. You can use 
it to record the starting and ending locations of the modules, as well as 
other important information, such as entry points and data segment bases. 
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iRMX" 86 SYSTEM MEMORY MAP WORKSHEET 


Configuration file name: 

Start address/ Module 

Data segment base 



Figure 4-2. System Memory Map 
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Example : 

This example shows how to prepare a memory map worksheet for a sample 
system* The sample system has the following characteristics: 

• 128K of contiguous RAM exists In the system. Thus the highest 
RAM address Is 1PFF:F. 

• The system consists of four modules: the Nucleus, the Debugger, a 
first-level application job, and the root job. 

• The ISBC 957B package Is going to be used to load the system Into 
memory. Therefore, the lowest available address Is 80:0. If the 
ISBC 957A package were to be used to load the system Into memory, 
the lowest available address would be 70:0. 

• The wake-up address space Is to be reserved for an ISBC 215. The CW^. 
configuration fo this device requires a default port address of 
100 : 0 . 

Figure 4-3 shows a prepared memory map for this system. When the modules 
are located, actual addresses can be recorded on this worksheet. 
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IRMX* 86 SYSTEM MEMORY MAP WORKSHEET 


Configuration file name: 

Start address/ Module Length Absolute 

Data segment base Address 



Figure 4-3. Example Memory Map Worksheet 
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LINK AND LOCATE THE SUBSYSTEMS AND APPLICATION JOBS 

After you have laid out your system, you can begin the iterative process 
of linking and locating your system* The following sections discuss this 
process* The first two sections discuss the procedures used to link and 
locate individual subsystems and application jobs* The third section 
describes how you must combine these individual link and locate processes 
and put together the entire application system* 


LINKING AND LOCATING THE SUBSYSTEMS 

The release diskette for each subsystem contains a SUBMIT file that 
assembles the subsystem’s configuration files, links the necessary 
modules together, and locates the subsystem at an absolute address* 

These SUBMIT files can be run on a Series II Microcomputer Development 
System* Chapters 6 through 11 identify the SUBMIT files for each 
subsystem and describe their parameters* This section provides an 
overview of the general process, describes some restrictions that you 
must adhere to in order to use the SUBMIT files as released, and 
describes the modifications you must make to the SUBMIT files if you run 
them on a Series III Microcomputer Development System* 


Overview 

Figure 4-4 Illustrates the procedure that most of the subsystem SUBMIT 
files follow in order to produce linked and located subsystems* This 
procedure Includes assembling (or compiling) the subsystem configuration 
file or files, linking the object files together with the subsystem 
library or libraries (which contain the actual code for the subsystem) 
and any necessary Interface libraries, and locating the resulting link 
module at absolute addresses* You can examine the individual SUBMIT 
files to determine the commands used, if you wish* However, after you 
have modified your subsystem configuration files to reflect your desired 
system, prepared the diskettes correctly, and placed them in the proper 
Series II development system disk drives, you need only use the ISIS-II 
SUBMIT command to run the SUBMIT files* (If you use a Series III 
development system, you will have to make additional modifications to the 
SUBMIT files in order to take advantage of the Series III capabilities*) 
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SUBSYSTEM 

CONFIGURATION 

FILE(S) 


ASM86 

OR 

PLM86 



Figure 4-4. Subsystem SUBMIT File Procedure 


Preparing Diskettes 

When you configure individual subsystems, you should never make 
modifications to the actual release diskettes. If you want to change any 
of the files on the release diskettes, such as the subsystem 
configuration files (named file.A86 or file.P86) or the SUBMIT files 
(named file.CSD), copy these files to another diskette first. 
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Placing Diskettes In the Proper Drives 

In order to use the subsystem SUBMIT flies as they are released^ you must 
place your diskettes In the proper drives of the INTELLEC development 
system* All subsystem SUBMIT files assume that you have a four drive 
development system and that you have placed diskettes In the drives as 
follows: 

FO A system disk containing LINK86, L0C86, ASM86 (version 3.0), 

and/or PLM86, as well as COPY, DELETE, and SUBMIT. 

FI A diskette on which you should place any modified versions of 

configuration files and copies of all SUBMIT files* The 
SUBMIT files also write the located code for the subsystems 
to this diskette* If you need to make changes to any file on 
a release diskette, you should first copy It from the release 
diskette to this diskette and then make the changes* If you 
copy a configuration file to this diskette and make changes 
to it, you will also have to make changes to Its associated 
SUBMIT file to correct the drive number for the configuration 
file* You should copy all SUBMIT files to this diskette 
before entering the SUBMIT command, so that you can leave 
your release diskettes In a write-protected state* 

F2 The subsystem release diskette* The SUBMIT file reads 

libraries and INCLUDE files from this diskette, but does not 
modify the diskette in any way* 

F3 a temporary and listing diskette* The SUBMIT file writes all 

Intermediate files (such as link files) to this diskette and 
deletes them when It no longer needs them* It also writes 
all listing files, link maps, and locate maps to this 
diskette* 


If you do not have a four-drive development system, or If your drives are 
set up with different disk mnemonics, you must modify the subsystem 
SUBMIT files and the subsystem configuration files to accomodate this* 


Using a Series III Development System 

If you use a Series III Microcomputer Development System in your 
configuration process, your versions of PLM86, ASM86, LINK86, and LOC86 
run under 8086 execution mode* Thus you will have to modify the 
configuration files and SUBMIT files In order to make them run correctly 
on your development system* Use the following guidelines when making 
these modifications* 
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Guidelines for Configuration Files 

• Ensure that each assembly language configuration file (a file 
whose name Is of the form “file. A86”) contains the NAME 
directive. This directive has the form: 

NAME modname 

where modname Is the name of your module. The one restriction on 
modname Is that It must be different from all other modname 
values In the linked system. Place this NAME directive at the 
beginning of the file. Refer to the 8086/8087/8088 MACRO 
ASSEMBLY LANGUAGE REFERENCE MANUAL FOR 8086-BASED DEVELOPMENT 
SYSTEMS for more Information concerning the NAME directive. 


Guidelines for SUBMIT Files 


• For each SUBMIT file (files whose names are of the form 
"flle.CSD"), add RUN before each ASM86, PLM86, LINK86, and L0C86 
command or put a RUN/EXIT pair around every set of ASM86, PLM86, 
LINK86, and LOC86 commands. Refer to the INTELLEC SERIES III 
MICROCOMPUTER DEVELOPMENT SYSTEM CONSOLE OPERATING INSTRUCTIONS 
for more Information about the RUN and EXIT commands. 

• Add the NOINITCODE control to every L0C86 command In your SUBMIT 
files. Refer to the lAPX 86,88 FAMILY UTILITIES USER'S GUIDE FOR 
8086-BASED DEVELOPMENT SYSTEMS for more Information about this 
control. 

• Remove the DATE control from every ASM86 and PLM86 statement. In 
most cases, this means that you will also be removing one of the 
formal parameters from the SUBMIT file. Therefore, when you 
Invoke the SUBMIT file, do not specify the date parameter, but 
Include the comma (,) as a placeholder. 

• Remove the MACRO control from the ASM86 statements In all SUBMIT 
files. 


LINKING AND LOCATING APPLICATION JOBS 

The most common method of linking and locating your application jobs Is 
to link the first-level job together with every job ultimately created by 
that first-level job and one or more Interface libraries. You must then 
locate this module at an absolute address. Figure 4-5 Illustrates this 
link and locate procedure. 
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If you do not link your first-level jobs together with their offspring 
jobs, you should link and locate the offspring jobs first* By doing 
this, you can obtain the absolute starting locations of the offspring 
tasks from the locate maps and specify these values in the CREATE$JOB and 
CREATE$TASK calls of their parent tasks before conq>lllng the parents* 

The following sections describe the individual link and locate commands 
in more detail, and describe the Interface libraries* The guidelines 
discussed in the "Using a Series III Development System" section of this 
chapter also apply to these link and locate commands* 
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Linking Application Jobs 

The LINK86 command is used to link your application jobs* This command 
is described in detail in the appropriate iAPX 86,88 FAMILY UTILITIES 
USER'S GUIDE* However, the format of the LINK86 command that you must 
enter is: 

LINK86 & 

:fx:app_job*ob j, & 

:fx: Interface* lib & 

TO ;fx:app_job*lnk MAP PRINT(:fx:app job*mpl) 


where : 

fx The appropriate disk mnemonic, indicating where the 

file resides* 

app_job*obj Object code for your application job* You do not need 
to provide this code on one file; you can link in 
several files or libraries at this point* 

interface *lib Interface libraries for the subsystems that your jobs 
make use of* You may have to link in several 
libraries at this point* These interface libraries 
are described in later paragraphs of this section* 

app_job*lnk Name of the file in which LINK86 places the module 
containing your linked application code* Use this 
file as the input file when locating your application 
job* 

app_job*mpl Name of the file in which LINK86 writes the link map 
for the application job* 


During the link process, you must link in a number of Interface 
libraries* These libraries contain the routines that satisfy external 
references to system calls that you make in your application code* The 
number and names of the libraries that you must link in with your 
application code depend on which subsystems your jobs. use and which model 
of PL/M-86 computation the jobs were compiled under* Table 4-1 shows the 
correlation between subsystems, models of computation, and interface 
libraries* Specify these libraries as the last modules in the LINK86 
input list so that they can satisfy references from all linked modules* 
Notice that no library exists for the small model of PL/M-86 computation; 
the IRMX 86 Operating System does not support applications compiled in 
small* 
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Table 4-1. Interface Libraries as a Function of PL/M-86 
Models and Subsystems 



COMPACT 

LARGE OR MEDIUM 

Nucleus 

RPIFC.LIB 

RPIFL.LIB 

Basic I/O System 

IPIFC.LIB 

IPIFL.LIB 

Application Loader 

LPIFC.LIB 

LPIFL.LIB 

Extended I/O System 

EPIFC.LIB 

EPIFL.LIB 

Human Interface 

HPIFC.LIB 

HPIFL.LIB 


Locating Application Jobs 

After you have used LINK86 to generate a link module for your application 
job, you must use L0C86 to bind this link module to absolute addresses. 
The appropriate lAPX 86,88 FAMILY UTILITIES USER'S GUIDE contains 
specific instructions on the use of the L0C86 command. 

Since you are laying out your test system by job rather than by class, 
use a combination of the ORDER and ADDRESSES controls on L0C86 to 
simplify the location process. Use the ORDER control to declare the 
order in which the classes of the job are to be located. Then declare 
the absolute address of the code class with the ADDRESSES control. LOC86 
automatically locates the rest of the classes following the code class. 

If you do this, a call to L0C86 appears similar to the following; 


LOC86 input_file TO output_flle & 

ORDER (CLASSES (CODE, DATA, STACK, MEMORY)) & 

SEGSIZE (STACK (stack_size) ) & 

ADDRESSES (CLASSES (CODE (absolute address))) & 

MAP PRINT (mapjfile) ~ & 

OBJECTCONTROLS (NOLINES, NOCOMMENTS, NOPUBLICS, & 

NOSYMBOLS) 


where: 

input_file Name of link file produced previously by LINK86. 

output_file Name of the file in which L0C86 writes the absolute 

module . 
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8tack_size Size of this job's stack. Use this control for 

those jobs requiring a statically allocated stack. 

A stack is statically allocated if you, and not the 
Operating System, specify a stack location and 
size. A minimum value of 200H should be specified, 
if this control is required; otherwise specify 
zero. It is recommended that you specify zero for 
this parameter and let the Nucleus dynamically 
allocate a stack whenever possible. This depends, 
however, on the model of PL/M-86 computation that 
you used when compiling your code. With 
dynamically allocated stacks, you specify the stack 
size in the %JOB macro call. Refer to the ”%JOB 
Macro" section of this chapter for further 
information. 

absolute _address Absolute starting location of the code segment of 

the job. You can obtain this address by examining 
the locate map of the previously located module. 
Refer to the next section of this chapter for 
further information about determining absolute 
addresses. 

map_file Name of the file in which L0C86 writes the locate 

map. Always generate the locate map. You need it 
in order to determine where to locate the next 
module. It also contains information that you need 
in order to generate the configuration file (as 
described in the "Build the Configuration File" 
section of this chapter). 


Use this form of the L0C86 command to locate each application job. 


THE ITERATIVE LINK AND LOCATE PROCESS 

As mentioned before, the link and locate process is an iterative 
process. You must link and locate one job, examine its locate map to 
determine its ending address, and use that information to link and locate 
the next job. This process can be broken down into the following steps: 

1. Link and locate the Nucleus first by submitting the NUCLUS.CSD 
SUBMIT file (described in Chapter 6). A parameter to this SUBMIT 
file is used to assign the Nucleus to absolute memory locations. 
Specify the lowest available memory locations for the Nucleus 
(1040 is recommended). 

2. Determine the ending address of the Nucleus from the locate map 
generated by L0C86. Record this value in the memory map. 
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3. Using the next available address as Input to a subsystem SUBMIT 
file (described in Chapters 7 through 13), link and locate the 
next subsystem* 

4. Determine the starting and ending addresses from the locate map* 
Record these values in the memory map* Also record the entry 
point address and data segment base in the leftmost column* You 
will use these values later when creating the configuration file* 

5* Go back to step 3 and continue until you have linked and located 
all of the subsystems* 

6* Use the next available address as the starting address for the 
root job* You do not have to link or locate the root job at this 
point* Instead, assume a length of 60(Si bytes for it and leave 
that amount of space* (This length is adequate for an 
application system with approximately 20 first-level jobs* If 
your system contains more than 20 first-level jobs, you should 
allow more space for the root job*) Record the starting and 
ending addresses on the memory map* 

7* Using the next available address as input to the ADDRESSES 
control of the L0C86 command, link and locate the first 
application job* 

8* Determine the starting address, the ending address, the entry 
point address, and the data segment base from the locate map and 
record these values in the memory map* 

9* Instead of using the next available address as input to the 

ADDRESSES control, leave some space between application jobs so 
that these jobs can grow during the debugging process, if 
needed* Use your own judgement as to how much space to leave, 
but if you are unsure, leave approximately IK bytes for growth* 
Add this padding factor to the ending address of the previously 
located module and record that figure as the starting address of 
the next module* 

10* Using the starting address recorded on the memory map as input to 
the ADDRESSES control of LOC86, link and locate the next 
application job. 

11* Go back to step 8 and continue until you have located all 
application jobs* 


After you perform this procedure once, you can create an additional 
SUBMIT file to locate all of the modules at once* This procedure can 
contain LINK86 commands for those jobs that may have to be relinked* The 
padding factors that you Included when assigning memory locations allow 
the modules to grow during the debugging process without affecting the 
L0C86 commands used to locate them* 
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NOTE 


The locate nap for the Nucleus always 
contains a warning message similar to 
the one shown In the following 
example. This Is a normal message for 
the Nucleus. It does not Indicate 
errors In the LOGS 6 command. 


Example : 


This example assembles the Nucleus configuration file, links and locates 
the full Nucleus, and records values from the locate map In the memory 
map worksheet. It makes the following assumptions about the system: 

• Disk drive FO on the INTELLEC Series II Development System Is a 
system disk containing L0C86. 

• Disk drive FI contains the user's configuration diskette. This 
diskette contains a copy of the Nucleus SUBMIT file NUCLUS.CSD. 

• Disk drive F2 contains the Nucleus release diskette. 


• Disk drive F3 contains a diskette on which the SUBMIT file can 
place temporary and Intermediate files. 

• The Nucleus Is going to be located at address 1040H. 


The following command calls a SUBMIT file to assemble the Nucleus 
configuration file and link and locate the Nucleus. Refer to Chapter 6 
for a complete description of the SUBMIT file. 

SUBMIT :F1:NUCLUS(04-01-81, 1040H) 

The located object module Is written to file NUCLUS on drive FI and the 
locate map to file NUCLUS. MP2 on drive F3. Figure 4-6 shows a part of 
this locate map. This map should be viewed as an exan^le only. It may 
differ from the one generated when you locate the Nucleus. 
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ISIS-II MCS-86 LOCATER, VI. 3 INVOKED BY: 
LOC86 & 

:f 3:nuclus.lnK TO :fi:nuclus & 

MAP PRINTC£3:nuclus.inp2) & 

NOLINES NQCUMMENTS NOSYMBOLS & 

SEGSIZE(data(2),stacK(0)) L 

ORDER(CLASS£S(code,data}) & 

ADDRESSESCCLASSES(COde(00l040h))) 
WARNING 26: DECREASING SIZE OF SEGMENT 

SEGMENT: STACK 


WARNING 26: DECREASING SIZE OF 

SEGMENT: DATA 


SYMBOL TABLE OF MODULE NBEGIN 
READ FROM FILE : F3 : NUCLUS . LNK 
WRITTEN TO FILE :F1:NUCLUS 


BASE 

OFFSET TYPE 

SYMBOL 


0104H 

OOOOH PUB 

NBEGIN 


MEMORY 

MAP OF MODULE NBEGIN 

READ FROM FILE :F3: 

NUCLUS. 

LNK 

WRITTEN 

TO FILE :F1 

:NUCLUS 


segment 

MAP 



START 

STOP 

LENGTH 

ALIGN 

OOOOOH 

003FFH 

0400H 

A 

01040H 

07077H 

603bH 

W 

07078H 

0709IH 

OOIAH 

W 

07092H 

07098H 

OOOAH 

w 

0709CH 

070AFH 

0014H 

w 

070B0H 

070B7H 

0008H 

w 

070B8H 

0708FH 

0008H 

w 

070C0H 

070C9H 

OOOAH 

w 

070CAH 

070D7H 

OOOEH 

w 

070D8H 

070F1H 

OOIAH 

w 

070F2H 

070F7H 

0006H 

w 

070F8H 

07127H 

0030H 

w 

07128H 

0712CH 

0OO5H 

w 


SEGMENT 


BASE OFFSET TYPE SYMBOL 


NAME 

CLASS 

(ABSOLUTE) 

CODE 

CODE 

OBJ.SEG 

CODE 

JOB.SEG 

CODE 

TASK-SEG 

CODE 

MB.SEG 

CODE 

SEM.SEG 

CODE 

REG.SEG 

CODE 

FS-SEG 

CODE 

INT-SEG 

CODE 

EXCEP-SEG 

CODE 

VALID.SEG 

CODE 

PIC-CNF-SEG 

CODE 


Figure 4~6> Example Nucleus Locate Map 
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0712EH 

0713FH 

0012H 


-IMR.PORT 

CODE 

07140H 

07151H 

0012H 

¥ 

.EOI.PORT 

CODE 

07152H 

07163H 

0012H 

¥ 

.1SR.READ.P0RT 

CODE 

07164H 

0716CH 

0009H 

B 

.PIC.INFO 

CODE 

071bDH 

07176H 

OOOAH 

B 

TIMER.CNF.SEG 

CODE 

07178H 

07178H 

OOOOH 

W 

CSEG 

CODE 

07178H 

07179H 

0002H 

w 

SLAVE.SEG 

CODE 

07180H 

07180H 

OOOOH 

G 

system.data.se 

-G.IU 

DATA 

07180H 

07181H 

0002H 

W 

DATA 

DATA 

07190H 

07190H 

OOOOH 

G 

??SEG 


07190H 

07190H 

OOOOH 

G 

LIB.87.PUB 


07190H 

07190H 

OOOOH 

¥ 

STACK 

STACK 

07190H 

07190H 

OOOOH 

¥ 

MEMORY 

MEMORY 


GKOUP MAP 

ADDRESS GROUP OR SEGMENT NAME 

07lt<0H DGROUP 

SYSTEM.DATA-SEG-ID 

DATA 

01040H CGKOUP 
CODE 
OBJ.SEG 
JOB_SEG 
TASK.SEG 
MB.SEG 
SEM.SEG 
KEG«SEG 
ES-SEG 
IM.SEG 
EXCEP.SEG 
VALID. SEG 
PIC.CNF.SEG 
.IMR.PORT 
-EOI.PORT 
_ISR.REAO.PORT 
.PIC. INFO 
TIMER.CNF.SEG 
CSEG 

SLAVE.SEG 


Figure 4-6. Exanq>le Nucleus Locate Miap (contlnxied) 
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Notice the warning message contained on the locate map* 
message that always occurs when you locate the Nucleus* 
alarmed by It. It does not Indicate an error. 

As you can see in Figure 4-6, the next available memory 
719:0. The last location used by the Nucleus Is 718:1. 
shown In Figure 4-7 contains these values. 


This Is a normal 
Do not be 

location Is 
The memory map 
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IRMX" 86 SYSTEM MEMORY MAP WORKSHEET 


Configuration file name; 

Start address/ Module Length 

Data segment base 


Absolute 

Address 


FFFF ; F 



(reserved) 

. . „ ^ 

reset vector \ 

FFFF ; 0 


1FFF;F 


Highest RAM address 

^ 


^ _ 


" V 


Application Job 

^ 


^ 


^ 


Root Job \ 

^ 


^ 


^ 


Debugger 

^ 719:0 


^ 


^ 718:1 


Nucleus 

^ 104:0 


Wake-up addresses 

^ 100:0 


Free space \ 

^ 80:0 


ISBC 957A/B monitor 

^ 40:0 


Interrupt vector \ 

^ 0:0 


Figure 4-7. Entering the Nucleus End Address on the Memory Map 
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BUILD THE CONFIGURATION FILE 

After you have created the memory map and located the jobs, you are ready 
to build the system configuration file or modify one of the existing 
files provided on the subsystem release diskettes* The system 
configuration file is an assembly language source file which must 
describe each first-level job, the system address blocks, and the system 
as a whole* The file must provide this Information in the form of macro 
calls* The macros used in the configuration file are; 

%JOB 

%SAB 

%SYSTEM 


These macros are described individually in the remainder of this 
section* However, the following Instructions apply to the configuration 
file as a whole and to all of the macros* 


In addition to placing macros in your system configuration file, 
you must also Include two other statements* The first statement 
in your system configuration file must be an $INCLUDE statement 
to Include the file CTABLE*MAC in the assembly of your 
configuration file* CTABLE*MAC is on the Nucleus release 
diskette and contains the definitions of the macros used in the 
remainder of the configuration file* The format of this 
statement is: _ 

$INCLUDE (;fx^CTABLE*MAC) 


where fx is the identifier of the drive containing the Nucleus 
release diskette* 

The last statement in your configuration file must be the END 
statement* The format of this statement is: 

END 


• You can Include space characters anywhere within your macro 
calls, in order to provide a more readable configuration file* 
Space characters consist of blank spaces* 

• You can spread your macro calls over several lines (such as 
placing one parameter on a line) if you specify the comment macro 
(%') on each line that is continued* An example of this is: 

%SAB (05000, %' start base 

OFFFF, %’ end base 

U) 

You must use these comment macros in order to exclude the 
carriage return and line feed characters from being processed by 
the assembler* 
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• For certain parameters you must specify a value of type addr, 
offset, or base* These are described as follows: 

addr An absolute address in the form base: offset* 

base An absolute paragraph address* 

offset A value which is offset from the specified base* 

You must supply these values exactly as they appear on the locate map 
produced by LOC86* The required radix for each of these values is 
hexadecimal* Therefore, do not Include the suffix H when specifying 
a value* For other parameter types (such as byte or word), you must 
explicitly specify a radix, with decimal the assumed default* 


%JOB MACRO 

The %JOB macro is used to specify parameters for first-level jobs. You 
must specify one %JOB macro for each optional subsystem first-level job 
and each application first-level job* Figure 4-8 contains the format of 
the %JOB macro. It is a worksheet that you can use to prepare the macro 
calls* The values in parentheses are suggested values. Use these 
suggested values for noncritical parameters. 
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Macro call: JOB (defines first-level jobs) 

Number of calls required: 

one for each first-level job 

CONFIGURATION FILE NAME: 


FORMAT: 





suggested 

parameter 

tz2± 

default value 

%JOB (dlrectory_slze. 

word 

(0) 

pool min, 

word 


pool max, 

word 

(OFFFFH) 

max objects. 

word 

(OFFFFH) 

max^tasks. 

word 

(OFFFFH) 

max_task_prlorlty. 

byte 

(0) 

exception handler entry j 

, addr 

(0:0) 

exception handler^mode. 

byte 

(1) 

job_flags. 

word 

(0) 

lnlt_task_prlorlty. 

byte 

(0) 

lnlt_task_entry. 

addr 


data_segment_base , 

base 

(0) 

s tack_polnter , 

addr 

(0:0) 

stack_slze. 

word 

(512) 

task_f lags) 

word 

(0) 


NOTES : 

!• Type addr is specified as base: offset* 

2. Types addr and base nnist be entered as hexadecimal numbers 

without the suffix H. Types word and byte default to decimal, 
but will accept all radix suffixes. 


Figure 4-8. %JOB Macro Worksheet 
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As you can see from Figure 4-8, the format of the %JOB macro is almost 
the same as the format of the CREATE$JOB system call described in the 
iRMX 86 NUCLEUS REFERENCE MANUAL^ The only difference between the two is 
that the %JOB macro omits the param$obj parameter and includes the 
exception__handler_entry and exception^Jiandlerjoaode parameters in line, 
rather than as a pointer to a structure containing this data. The other 
parameters are the same. For completeness, a short description of each 
of the parameters of the %JOB macro follows. For more detailed 
information, refer to the description of the CREATE$JOB system call in 
the iRMX 86 NUCLEUS REFERENCE MANUAL. 


directory size 


pool min 


pool max 


max_ob jects 


max tasks 


Maximum allowable number of entries 
in this job*s object directory. A value of 
zero indicates that no directory is to be 
created. The maximum value for this 
parameter is OFFOH. 

Minimum allowable size of the job's memory 
pool, in 16-byte paragraphs. 

Maximum allowable size of the job’s memory 
pool, in 16-byte paragraphs. 

Maximum number of objects that can exist 
simultaneously in the job. A value of 
OFFFFH indicates unlimited objects. 

Maximum number of tasks that can exist 
simultaneously in the job. A value of 
OFFFFH indicates unlimited tasks. 


max_jtask_priority Maximum allowable priority of tasks in the 

^ job. Specify a value in the range 0 to 255 

decimal. A value of zero indicates that the 
priority of the root task is the maximum 
allowable. 

exception_handler_entry Pointer to the start address of the job’s 

exception handler. A value of 0:0 indicates 
that the job uses the exception handler 
specified in the %SYSTEM macro (described 
later in. this chapter). 

except ion_handler_mode Encoded indication of the job’s exception 

mode. Values are interpreted as follows: 

Pass control to 
value exception handler 

0 Never 

1 On programming error conditions only 

2 On environmental conditions only 

3 On all exceptional conditions 
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job_f lags 


init_task_priorlty 

init_task_entry 

data_segment_base 

stack_pointer 


stack size 


Information that the Nucleus needs to create 
and maintain the job. Bits in this word are 
Interpreted as follows: 

bit meaning 
15-2 Reserved. 

1 If set to 0, the Nucleus validates 

parameters for all system calls made 
by tasks in this job or its 
offspring. Refer to the "Parameter 
Validation" section of Chapter 6 for a 
further discussion of parameter 
validation. 

If set to 1, the Nucleus does not 
validate parameters for tasks in this 
job. 

0 Reserved. 


Priority of this job's initialization task. 

A value of zero assigns the initialization 
task a priority equal to the max_job_priority 
parameter. 

Entry point of this job's initialization task. 

Base value of the initialization task's data 
segment. A value of zero indicates that the 
task Itself assigns the data segment. 

Address of the initialization task's stack. 

A value of 0:0 causes the Nucleus to allocate 
a stack segment to the task and initialize 
the SS register to the base address of this 
segment and the SP register to the value of 
the stack_size parameter. It is recommended 
that you specify 0:0 for this parameter. 

This permits dynamic stack allocation and 
deallocation. 

Size in bytes of the Initialization task's 
stack segment. Specify 200H as a minimum 
value for this parameter. You must enter a 
value for this parameter even if the job uses 
dynamically allocated stacks. 
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taskJElags Information that the Nucleus needs to create 

and maintain the job^s initial task. Bits in 
this word are interpreted as follows: 

bit meaning 

15-1 Reserved bits which should be set to 
zero. 

0 If one, the initial task contains 

floating-point instructions which 
require the 8087 NDP for execution. 

If zero, the Initial task contains no 
floating point instructions. 

For your PL/M-86 jobs, the parameters that you must specify for each %J0B 
macro depend on the PL/M-86 size control. The following sections outline 
the differences with references to the appropriate %J0B macro parameters. 


Data Segment Allocation 

PL/M-86 large model procedures . Large model procedures have statically 
allocated data segments. However, you do not have to specify data 
segment values because the PL/M-86 compiler generates code that 
automatically initializes the data segment (DS) register for each 
procedure when that procedure begins executing. Therefore, for large 
model procedures, set the data_segment_base parameter to zero. 


PL/M-86 medium and compact model procedures . These procedures also have 
statically allocated data segments. However, the compiler does not 
automatically initialize the data segment register for medium and compact 
models of computation. Therefore, if you compile a procedure using 
either of these models, you must specify the base address of that 
module *s DGROUP as the data__segment parameter of the %J0B macro. Obtain 
the base address from the locate map produced by LOC86. (DGROUP includes 
the data, stack, and memory segments/classes for the medium model and the 
data segment/class for the compact model. The constant segment/class is 
included in CGROUP if the ROM compiler control is used.) 


Stack Allocation 

PL/M-86 large and compact models . The Operating System must dynamically 
allocate stacks for procedures compiled in these models. Thus, you must 
specify 0:0 for the stack^ointer parameter of the %J0B macro. The 
Operating System allocates a stack to the job with a size that you 
specify in the stackjsize parameter of the %J0B macro. 


4-27 


s 



LOCATING A TEST AND DEVELOPMENT SYSTEM IN RAM 


When you use LOC86 to locate these procedures, you must use the SEGSIZE( 
STACK(O)) control. Refer to "The Locating Application Jobs" section of 
this chapter for further information about this control* 


PL/M-86 medium models* Procedures compiled using the medium model 
require statically allocated stacks. Thus, for these procedures, you 
must specify the address of the stack in the stackjpolnter parameter of 
the %JOB macro* Use the value indicated in the locate map when 
specifying this parameter. You should also specify the size of the stack 
in the stack^size parameter of the %JOB macro* Use the same size as you 
specified in the SEGSIZE( STACK( ... ) control of the LOC86 command. 

Refer to "The Locating Application Jobs” section of this chapter for 
further information concerning the LOC86 command. 


%SAB MACRO 

The %SAB macro declares the size and location of each system address 
block. A system address block is an area of addressable memory not 
available as dynamically reusable memory. This Includes ROM, nonexistent 
memory, and RAM reserved for jobs. The Nucleus needs to know where these 
reserved areas are so that it does not reassign them. Look at the memory 
map worksheet that you filled out for your system and use %SAB macro 
calls to reserve all memory needed for the Nucleus, subsystems, 
application jobs, interrupt vector, reset vector, iSBC 957A/B workspace, 
and ROM. 

The format of the %SAB macro is shown in Figure 4-9. This figure is a 
worksheet that you can use to prepare the macro calls. 
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Macro 

call: SAB (for system address 

blocks) 


Number 

of calls required: 

one or more 



CONFIGURATION FILE NAME: 






FORMAT 

• 

• 


suggested 



parameter 


default 

value 

%SAB 

(start base. 

base 




end base, 

base 




type) 

see note 
1 

u 


%SAB 

(start base, 

base 




end base. 

base 




type) 

see note 
1 

u 


%SAB 

(start_base. 

base 




end_base. 

base 




type) 

see note 
1 

u 



NOTES: 


1. The type parameter Is reserved for future use. Enter the 
character U for this parameter. 

2. A SAB is declared between start_base:0 and end_base:F, 
inclusive. 

3. Types addr and base must be entered as hexadecimal numbers 
without the suffix H. Types word and byte default to decimal 
but will accept all radix suffixes. 


Figure 4-9. %SAB Macro Worksheet 
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The parameter of the %SAB macro are described as follows: 


start base 


end base 


type 


A base value that defines the beginning of the 
SAB. The starting address of the SAB Is 
Interpreted as start_base:0. 

A base value that defines the end of the SAB. The 
end address of the SAB Is Interpreted as 
end_base:F. 

Reserved for future use. Enter the character U 
for this parameter. 


When placing %SAB macro calls In the system configuration file, you must 
observe the following guidelines: 

• You must order your %SAB macro calls by the start addresses of 
the memory that they declare (from smallest to largest). 

• You must declare the Interrupt vector as a system address block 
with a %SAB call. 

• You must make %SAB calls for all ROM In your system. 

• You must not overlap system address blocks (that Is, %SAB macro 
calls must declare discrete areas of memory). 

• Each block of memory not declared with a %SAB macro call must be 
at least (minimum transfer size +48 decimal bytes) In length. 
Refer to the "%SYSTEM Macro" section of this chapter for a 
description of the minimum transfer size. 

• The first block of memory not declared with a %SAB macro call 
must be at least 160 decimal bytes long. 


%SYSTEM MACRO 

The %SYSTEM macro Is used to declare parameters that affect the system as 
a whole. You must declare exactly one %SYSTEM macro for your entire 
system and place It Immediately prior to the END statement In the system 
configuration file. Figure 4-10 contains the format of the %SYSTEM 
macro. This figure Is a worksheet that you can use to prepare the macro 
call. The values In parentheses are suggested values. Use these 
suggested values for noncrltlcal parameters. 
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Macro call: SYSTEM (system parameters) 

Number of calls required: exactly one 

CONFIGURATION FILE NAME 


FORMAT: 



suggested 



parameter 

gp.g 

default 

value 

%SYSTEM 

(nucleus entry. 

base 




rod^size. 

word 

(30) 



min^Jtrans size. 

word 

(64) 



debugger, 

see note 
1 

(A) 



default_e_h_provided. 

see note 
2 

(N) 



exception^jnode ) 

word 




NOTES: 

1. Valid entries for the debugger parameter include: 

A Debugger available 
N No debugger available 

2. Valid entries for the default_e_h_provlded parameter include: 

Y Yes 
D Debugger 
N No 

3. Types addr and base must be entered as hexadecimal numbers 
without the suffix H. Types word and byte default to 
decimal) but will accept all radix suffixes* 


Figure 4-10. %SYSTEM Macro Worksheet 
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The parameters of the %SYSTEM macro are described as follows: 

nucleus^entry Base value of the code segment of the Nucleus* 

For this parameter, specify the base portion of 
the value shown on the Nucleus locate map* 

rod_j3ize Maximum number of objects that can be cataloged 

in the root object directory. 

mlnjtrans_size Minimum amount of memory, in 16-byte paragraphs, 

that the Nucleus allows to be transferred 
between jobs. If your application programs 
consistently request memory in larger than 
64-paragraph blocks, you should adjust this 
parameter to reflect this, in order to cut down 
on system overhead involved with transferring 
memory. However, do not specify a value much 
larger than the amount of memory your programs 
ordinarily request or memory fragmentation will 
occur, and the additional memory will be wasted. 

debugger Letter that indicates whether or not the 

Debugger is available. Possible values include: 

A The Debugger is available. 

N No Debugger is available. 

default__e_hjprovided Letter that indicates the system default 

exception handler. Possible values include: 

Y A user-supplied exception handler is 

the system default. 

D The Debugger is the system default 

exception handler. 

N No default exception handler is 

specified. 

If you specify Y for this parameter, you must 
create your own exception handler, designate it 
to be a public procedure having name RQSYSEX, 
and link it to the root job. If you specify D 
for this parameter, make sure to include the 
Debugger in your system. Even if you include 
the Debugger in your system, you do not have to 
specify it as the system default exception 
handler. 
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mode Encoded Indication of the exception handler 

mode* Values are Interpreted as follows; 

Pass control to 
value exception handler 

0 Never 

1 On programming error conditions 

only 

2 On environmental conditions only 

3 On all exceptional conditions 


MACRO PARAMETERS FOR SUBSYSTEMS 

Tables 4-2 and 4-3 list parameter values for the %JOB and %SYSTEM calls 
which you should use, depending on the subsystems In your application 
system. These tables list recommended values. A blank entry In either 
of the tables Implies that you must determine this value. Notes for 
these tables follow the tables. 

Notice that Tables 4-2 and 4-3 contain no entries for the Human 
Interface. You do not specify a %JOB macro for the Human Interface In 
order to Include It In your application system. Instead, you must 
Include the Human Interface as an I/O job during the configuration of the 
Extended I/O System. Refer to Chapters 12 and 13 for further Information. 
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Table 4-2. Suggested %JOB Values for Optional Subsystems 


Macro 

Parameter 

1 

Debugger 

Value 

Terminal Handler 
Value 

I/O System 
Value 

%JOB 

directory_size 

0 

0 

0 


pool_min 

170H (without 
NDP support) 

85H 

500H 



178H (with NDP 
support) 




pool^max 

OFFFFH 

OFFFFH 

500H 


max objects 

OFFFFH 

OFFFFH 

OFFFFH 


max^tasks 

OFFFFH 

OFFFFH 

OFFFFH 


max_jo b_prlori ty 

0 

0 

0 


exception_hand- 

ler_entry 

0:0 

0:0 

0:0 

1 


except ion_hand- 
ler^mode 

0 

0 

1 

0 


job_f lags 

0 

0 

0 


inlt_task__pri- 

ority 

0 

0 

128 


init_task_ent ry 

note 1 

note 1 

note 1 


data^s egment_ 
base 

0 

0 

0 


stack_j)ointer 

0:0 

0:0 

0:0 i 


stack_size 

300H 

300H 

200H 


task^flags 

0 (without 
NDP support) 

0 

0 



1 (with NDP 
support) 
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Table 4-2. Suggested %JOB Values for Optional Subsystems 

(continued) 


Macro 

Parameter 

Application 

Loader 

Value 

Extended I/O 
System 
Value 

%JOB 

directory's Ize 

0 

0 


pool_inln 

20H 

180H 


pool_max 

20H 

180H 


max^ob jects 

50 

QFFFFH 


max_tasks 

5 

OFFFFH 


max_job_priority 

0 

0 


exception_hand“ 

ler_entry 

0:0 

0:0 


exceptlon_hand- 

ler_mode 

0 

0 


job_flags 

0 

0 


lnit_task_pri- 

ority 

130 

140 


init_task _entry 

note 1 

note 1 


data_s egment_ 
base 

0 

0 


stack_polnter 

0:0 

0:0 


stack_slze 

200H 

300H 


task _flags 

0 

0 
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Table 4-3. Suggested %SYSTEM Values for Optional Subsystems 


Macro 

Parameter 

Debugger 

Value 

Terminal 

Handler 

Value 

I/O System 
Value 

%SYSTEM 

nucleus_entry 

note 2 

note 2 

note 2 


rod^size 

30 

30 

30 



40H 

40H 

40H 


debugger 

A 

note 3 

note 3 


def aul t_e_h_ 
provided 

D 

note 3 

note 3 


mode 

3 

note 4 

note 4 

Macro 

Parameter 

Application 

Loader 

Value 

Extended I/O 
System 
1 Value 

1 

%SYSTEM 

nucleus_entry 

note 2 

note 2 



rod_size 

30 

30 



mlnjt: rans_s ize 

40H 

4 OH 



debugger 

note 3 

note 3 



default_e_h_ 

provided 

note 3 

note 3 



mode 

note 4 

note 4 
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NOTES FOR TABLES 4-2 AND 4-3: 

1* Determine the values of the initialization task entry points from 
the absolute address specified as input to LOC86 (or the SUBMIT 
file used to locate the subsystem). The base portion of this 
address is the base of the entry point. The offset portion of 
the entry point is 0. Thus the entry points for all subsystems 
are of the form ”base:0”. 

2. Determine this value from the Nucleus locate map. Use the base 
portion of the code class start address. 

3. These values vary depending on whether you include the Debugger 
in your application system. 

4. These values vary depending on which exceptions are to be handled 
by the exception handler. 


CREATING THE CONFIGURATION FILE 

After you have filled out all of the necessary %J0B, %SAB, and %SYSTEM 
worksheets, use a text editor to build one file containing all of these 
macro calls. You can create an entirely new file or use one of the files 
available on the release diskettes. Each optional subsystem release 
diskette contains an example system configuration file. This file is 
named xROOT.A86, where x indicates the subsystem with which it is 
associated (for example, IROOT.A86 is contained on the I/O System release 
diskette and LROOT.A86 on the Application Loader release diskette). Each 
one of these files contains %J0B calls for that particular subsystem and 
all other required subsystems, %SAB calls, and a %SYSTEM call. You can 
use any of these example system configuration files as your system 
configuration file by filling in the absolute addresses, adding %J0B 
calls for your application jobs, and modifying the %SAB calls to reflect 
your hardware environment. 

After you create or modify your system configuration file, write its name 
on the macro worksheets, because you must specify this name later, during 
the root job generation process. 

When creating or modifying your system configuration file, remember the 
following things: 

• Place an $INCLUDE statement for the file CTABLE.MAC as the first 
statement of the file and the END statement as the last statement 
of the file. 

• Enter all of the %J0B, %SAB, and %SYSTEM macro calls into this 
file. You can enter them in the same format as shown on the 
worksheets if you place comment macros (%’) at the end of each 
continued line, or you can place the parameters for each macro 
call on a single line. Enter the required %SAB calls for your 
system, a %J0B call for each first-level job, and one %SYSTEM 
call. Place the %SYSTEM macro call immediately before the END 
statement* It must be the last macro call. 
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• It does not matter whether you place %JOB or %SAB calls first in 
the file. However, the order In which you enter the individual 
%JOB and %SAB calls is important* The %SAB calls must abide by 
the order restrictions described in the ”%SAB Macro" section of 
this chapter* The %JOB call order is important because the root 
job initializes jobs in the order that their %JOB calls appear in 
the system configuration file* Always place the %JOB calls in 
the following order: 

1* Subsystem first-level jobs, in the following order: 

Terminal Handler and/or Debugger (in any order) 

Basic I/O System 
Application Loader 
Extended I/O System 

You can omit the Application Loader and still Include the 
Extended I/O System* However, if you include the Human 
Interface as an I/O job during Extended I/O System 
configuration (refer to Chapters 12 and 13), you must 
Include the Application Loader and place its %JOB macro in 
the Indicated position* 

2* Application first-level jobs 

Place the subsystem first-level %JOB calls first so that the 
services of the subsystems are available to the remainder of the 
flrst-leVel jobs when the first-level jobs are initialized* 

The order in which you place %JOB calls for your application jobs 
depends on the content of these jobs* Any job whose services are 
immediately used by other jobs should be initialized before the 
other jobs; thus you should place its %JOB call earlier in the 
file* 

After you have created the configuration file or modified one of the 
existing ones, you can go on to the next section and generate the root 
job* 


GENERATE THE ROOT JOB 

In order to generate the root job, you must do three things: 

• Assemble the configuration file 

• Link the root job and its associated modules 

• Locate the root job 

The Nucleus release diskette contains a SUBMIT file, CROOT*CSD, which you 
can use to perform all three of these functions* In order to use this 
SUBMIT file, you must first prepare your diskettes and place them in the 
proper drives as explained in the "Linking and Locating the Subsystems" 
section of this chapter* Then you can enter the following command: 
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SUBMIT ;fxiCROOT( file, date, loc_addr) 
where: 

fx The appropriate disk identifier, indicating the drive 

containing CROOT.CSD. 

file Name of the system configuration file. You should not 

Include a disk identifier or an extension with this 
file name. The SUBMIT file assumes that this file 
resides on drive FI and has the extension "A86". The 
SUBMIT file places the located root job on drive Fl in 
a file of the same name but without the extension and 
the link and locate maps on drive F3 in files of the 
same name but with extensions "MPl" and "MP2" 
respectively. The SUBMIT file also expects file 
CROOT.LIB to be available on drive F2. 

date Date on which this configuration takes place. 

loc__addr Address at which to locate the root job. Examine the 

memory map that you made earlier to determine the 
ending address of the last module that you located. 

Add a padding factor to that value, if necessary, and 
use the sum for the starting address of the root job. 
If you want to specify this value as a hexideclmal 
number, you must include the suffix H. 


NOTE 


If you are providing your own system 
exception handler, you must assemble it 
and modify CROOT.CSD in order to link 
the exception handler in with the root 
job. Its declaration must occur just 
prior to CROOT.LIB in the LINK86 
portion of CROOT.CSD. 


LOAD AND TEST THE SYSTEM 


After you have located all of your jobs (Nucleus, subsystem jobs, 
application jobs, and root job), you are ready to load the system into 
RAM and test it. Use the ICE-86 in-circuit emulator or the iSBC 957A/B 
package to load your system from disk into RAM. The procedure for using 
ICE-86 is available in the ICE-86 IN-CIRCUIT EMULATOR OPERATING 
INSTRUCTIONS FOR ISIS-II USERS. The procedure for using the iSBC 95 7A 
package is described in the iSBC 957A INTELLEC - iSBC 86/12A INTERFACE 
AND EXECUTION PACKAGE USER’S MANUAL. The procedure for using the 
iSBC 957B package is described in the USER’S GUIDE FOR THE iSBC 957B iAPX 
86, 88 INTERFACE AND EXECUTION PACKAGE. When loading into 
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RAM, be sure to load the root Job last, so that its starting address gets 
correctly loaded into the code segment (CS) and instruction pointer (IP) 
registers. 

When you have loaded your system, test it, correct any errors, reassemble 
or recompile any appropriate program code, re-link and relocate the 
necessary modules, and load the system again with the ICE-86 in-circuit 
emulator or the iSBC 957A/B package. You can continue this procedure 
(essentially a subset of the procedures described in this chapter) until 
you have created an error-free system. Then you can copy your final 
system to IRMX 86-formatted disks and use the Bootstrap Loader to load 
your system or you can build a final ROM/RAM-based system. 

If you are going to use the Bootstrap Loader, refer to Chapter 11 of this 
manual for configuration information. Also refer to the iRMX 86 LOADER 
REFERENCE MANUAL for information on how to use the Bootstrap Loader. 

If you are going to build a final ROM/RAM-based system, you can, in order 
to shorten the load time, burn your fully tested and completely debugged 
jobs into PROM while still testing and developing other jobs in RAM. 

Then, each time you reload your system, you need only load the jobs you 
are still working on. 

Chapter 5 describes the procedures necessary to configure a ROM/RAM 
system. In general, it describes how to turn a completely debugged RAM 
system into a ROM/RAM system. If you want to burn your jobs into PROM as 
you finish testing and debugging them, make sure that all the fully 
tested and debugged jobs are configured as described in Chapter 5. The 
remaining jobs can be tested in RAM and burned into PROM as they are 
completed. 



CHAPTER 5. CONFIGURING THE FINAL ROM/RAM BASED SYSTEM 


If you have followed the procedures outlined in Chapters 3 and 4 of this 
manual, you should have a fully tested RAM-based iRMX 86 application 
system. In order to create the final ROM/RAM system, you should do the 
following: 

• Minimize the memory address space requirements of your system by 
eliminating the padding factor you used originally when locating 
your jobs. 

• Locate your system so that all the ROM-resident segments are 
contiguous. 

• Test your final system in RAM first, locate it into ROM/RAM, and 
burn the appropriate parts into PROM. 


The remainder of this chapter discusses these procedures in more detail. 
You should read the entire chapter, however, before modifying your 
system. The order in which you perform these procedures depends on your 
individual system requirements. 


MINIMIZING THE MEMORY ADDRESS SPACE 


When you originally located your first-level application jobs, you 
Included padding factors in the calculations used to determine starting 
addresses of succeeding jobs. The additional space allocated with the 
padding factors allowed you to make small changes in your programs that 
Increased their sizes without changing the LOC86 commands used to locate 
them. The modules, despite increasing in size, did not overlap each 
other. In your final ROM/RAM system, you have already debugged all of 
your programs; their sizes are fixed. So now you can eliminate any extra 
space existing between modules, if you desire. You also estimated the 
size of the root job and included this estimate in the %SAB macro call. 
You can now make a much better estimate of the size of the root job and 
modify your %SAB macro call to indicate this. 

Follow the procedures outlined in the "Locate the Jobs" section of 
Chapter 4 to locate your application first-level jobs again. This time, 
however, leave out the padding factors between jobs. Then modify the 
configuration file by changing the %SAB and %JOB macro calls as follows: 

• Change the %JOB macro call for each application first-level job 
to reflect the new location of the job. 

• Change the %SAB macro calls to reflect the smaller size of 
reserved memory. 
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• Also j change the %SAB macro call to more accurately reflect the 
size of the root job* You can make a better estimate of Its size 
because you have already located It during the testing phase* 

Use the locate maps generated for It to make a size estimate* 


If the starting address of the root job has changed, specify this new 
address In the CROOT.CSD file* Then, re-submlt CROOT.CSD* (The section 
In Chapter 4 entitled "Generating the Root Job” describes this 
procedures. ) 

After you have located your system, load It Into RAM and test It again to 
make sure that It functions correctly. 

You can perform this procedure In conjunction with the one described In 
the next section. However, It might be wise to perform them separately 
In order to localize any possible errors. 


LOCATING THE ROM/RAM BASED SYSTEM 

When you located your Initial test and development system, as described 
In Chapter 4, you located It by job. That Is, If you had three jobs, 
they were laid out as shown In Figure 5-1. 


high memory 

Job 3 MEMORY class 
Job 3 STACK class 
Job 3 DATA class 
Job 3 CODE class 


Job 2 MEMORY class 
Job 2 STACK class 
Job 2 DATA class 
Job 2 CODE class 


Job 1 MEMORY class 
Job 1 STACK class 
Job 1 DATA class 
Job 1 CODE class 

low memory 


Figure 5-1. Memory Layout of a RAM-based System 
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This was relatively easy; it allowed you to use the ORDER control in 
LOC86 and specify only one address for each job with the ADDRESSES 
control* The SUBMIT files used to link and locate each of the subsystems 
used this method also* However, when configuring a ROM/RAM system, you 
should lay out the system by class, not by job* All of the ROM-resident 
segments from all of the jobs should be positioned together* Likewise, 
all of the RAM-resident segments should be positioned together* Thus, if 
you had the same three jobs and were laying out a ROM/RAM system, you 
should structure your memory as shown in Figure 5-2* 


high memory 

Job 3 CODE class 

Job 2 CODE class ROM 

Job 1 CODE class 


Job 3 MEMORY class 

Job 3 STACK class 

Job 3 DATA class 

Job 2 MEMORY class 

Job 2 STACK class RAM 

Job 2 DATA class 

Job 1 MEMORY class 

Job 1 STACK class 

Job 1 DATA class 


low memory 


Figure 5-2* Memory Layout of a ROM/RAM System 


All of the code classes are located in the upper memory, or ROM, and the 
remainder are located in RAM* 

As you can see, in order to transform your RAM-based system into a 
ROM/RAM system, you must locate your jobs again* Before you do that, 
however, you should prepare a new memory map* 


PREPARE A NEW MEMORY MAP 

To prepare a new memory map, follow the procedures outlined in the 
"Preparing a Memory Map" section of Chapter 4, with one exception* In 
this map record not only the first available RAM address and the last 
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available RAM address, but also the first available ROM address and the 
last available ROM address. You need this information on your memory map 
because for ROM/RAM systems you must specify a location for both the 
ROM-resident code classes and RAM-resident classes. 


LOCATE THE MODULES 

The procedure for locating the modules of a ROM/RAM system, like that for 
a RAlI-based system, is an iterative procedure. You locate one module, 
record its addresses in the memory map, and use those values to determine 
where to locate the next module. The format of the LOC86 command used to 
locate these modules is slightly different from the one used to locate 
the RAM-resident system. The format of this command when using a Series 
II development system is as follows: 


L0C86 input_file TO output^file & 

ORDER (CLASSES (DATA, STACK, MEMORY)) & 

SEGSIZE (STACK (stack_slze) ) & 

ADDRESSES (CLASSES (CODE (rom_address) , & 

DATA (ram ^ddress))) & 

MAP PRINT (map file) & 


OBJECTCONTROLS(NOLINES, NOCOMMENTS, NOPUBLICS, & 
NOSYMBOLS) 


where: 


input__file Name of the link file produced previously by LINK86. 

output__file Name of the file in which LOC86 writes the absolute 

module. 


data size 


When locating the Nucleus, specify a value of 2H. 


stack size 




rom address 


ram address 


If you are locating the Nucleus, the stack size need 
not be greater than zero. Otherwise, specify the 
size of this job*s stack. Use this control for those 
jobs requiring a statically allocated stack. If this 
control is required, specify a minimum value of 200H; 
otherwise specify zero. 

Absolute starting location of the ROM-resident class 
(code class) of the module. 

Absolute starting location of the RAM-resident 
classes of the module. 


map file 


Name of the file in which LOC86 writes the locate map 


If you have a Series III development system, you must also follow the 
additional guidelines listed in the "Using a Series III Development 
System" section of Chapter 4. 
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Use this form of the LOC86 command to locate the Nucleus, each optional 
subsystem first-level job, the root job, and each application first-level 
job. The ORDER and ADDRESSES controls of this command differ from those 
of the RAM-based LOC86 command (refer to the "Locating Application Jobs” 
section of Chapter 4). In this command, the ORDER control does not 
mention the code class. The ADDRESSES control requires that you enter 
two absolute addresses; one to locate the code class in ROM and one to 
locate the remaining classes in RAM. 

The SUBMIT files contained on the subsystem release diskettes that link 
and locate the subsystems and the root job do not use this form of the 
LOC86 command. In order to use these SUBMIT files to create a 
ROM/RAM-based system, you must modify the LOC86 commands contained in 
these files so that they conform to the methods just described. 

One method of locating your ROM/RAM system is as follows: 

1. Locate the Nucleus first. Assign its data class to the lowest 
available RAM address and its code class to the lowest ROM 
address. 

2. Determine the ending addresses of the code class and the memory 
class from the locate map generated by LOC86. Record these 
addresses on the memory map. 

3. Using the next available ROM and RAM addresses as input to LOC86, 
locate the first optional subsystem. 

4. Determine the ending addresses of the code class and the memory 
class from the locate map generated by LOC86. Record these 
addresses on the memory map. Also record the entry point address 
on the memory map. You need to know this address in order to 
specify it in the %JOB macro call. 

5. Go back to step 3 and continue until you have located all of the 
subsystems and all of the application jobs. 


After you have performed this procedure, follow the procedures outlined 
in the "Build the Configuration File” section of Chapter 4 in order to 
modify the configuration file and locate the root job. Note that you 
must modify the CROOT.CSD file in order to locate the root job as 
described in this chapter. You must also reserve all areas of RAM needed 
by the located modules. 


TESTING THE SYSTEM IN RAM 


Before you actually locate a ROM/RAM system, it is recommended that you 
follow the procedures outlined in the previous section, but specify RA14 
addresses for all classes. Then you can load the system into RAM and 
test it before burning code into PROM. After doing this, you can adjust 
the addresses to reflect a ROM/RAM system and build your final system. 


5-5 




CHAPTER 6. CONFIGURING THE NUCLEUS 


The Nucleus provides system calls and features to support a wide variety 
of application software activities in a flexible hardware environment. 

Its structure allows you to take advantage of a breadth of support 
without sacrificing memory size or performance. If, after writing the 
code for your application system, you discover that you never make 
certain system calls or never make use of certain Nucleus features, you 
can exclude these system calls and features from the Nucleus of your 
application system. 

The Nucleus also supports a variety of hardware environments. You can 
specify several options for your interrupt controllers and timer. You 
can also include an 8087 Numeric Data Processor in your system. 

Hie process of including or excluding system calls and features and 
specifying the component environment is called Nucleus configuration. 
Nucleus configuration involves the following operations: 

• Selecting the internal Nucleus features that you want to include 
in your application system and omitting the rest. 

• Selecting the Nucleus system calls that you want to Include in 
your application system and discarding the rest. 

• Identifying certain hardware components that make up your system, 
and selecting the attributes of these Components. 

You perform these operations by making modifications to two 
Intel-supplied Nucleus configuration files: NTABLE.A86 and NDEVCF.A86. 
NTABLE.A86 defines the system call and feature configuration; NDEVCF.A86 
defines the component configuration. These files are assembly language 
source files which are contained on the Nucleus release diskette. Figure 
6-1 illustrates the structure of these files. After modifying the files, 
you must assemble them and link them with the rest of the Nucleus object 
files and libraries. The following sections describe this configuration 
process in detail. 
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Figure 6-1. NTABLE.A86 and NDEVCF.A86 Structure 


MODIFYING NTABLE.A86 

As released, NTABLE.A86 defines the full complement of Nucleus system 
calls and Internal features. To eliminate system calls or features, you 
must modify this file. 

NTABLE.A86 consists of a series of macro calls. A macro, which 
corresponds In name to a system call or Nucleus Internal feature, gives 
directions to the assembler to Include the code for that system call or 
feature In the Nucleus. In order to exclude a system call or feature 
from your system, delete the metacharacter of the associated macro call 
(%), and replace It with the comment character (;). By doing this, you 
change the macro call Into a comment and prevent the assembler from 
evaluating It. 
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The file NTABLE»MAC, which is available on the Nucleus release diskette> 
contains the definitions of all macros called in NTABLE.A86. NTABLE.A86 
contains an $INCLUDE statement for NTABLE.MAC, which Includes it in the 
assembly of NTABLE.A86. 

The following sections describe modifying NTABLE.A86 to select features 
and system calls. 


SELECTING NUCLEUS INTERNAL FEATURES 

If you do not modify NTABLE.A86, the following Internal features are 
Included with the Nucleus: 

• parameter validation 

• system default exception handler 

You can exclude any or all of these features in order to reduce code size 
and/or Increase performance by modifying the feature configuration table 
portion of NTABLE.A86. Figure 6-2 illustrates this table. In order to 
exclude a feature, replace the percent-sign (%) at the beginning of the 
corresponding macro call with a semicolon (;). The following sections 
describe each of these Nucleus internal features. 


SINCLUDE(:F2:NTABLE.«<AC) 

SCJECT 


§$9§$99§099§9§99999§9t§9999i99999§999f9999999999999§t99$f99999999 

• 

t NUCLEUS feature CONFIGURATION TABLE 

1 

! TO LEAVE OUT A FEATURE, CHANGE THE TO THE COMMENT 

t CHARACTER . 

t 


tPARAMElER.VALIOATION 

%system.exception.handler 


Figure 6-2. Feature Configuration Table (NTABLE.A86) 


Parameter Validation 

A system call validates input parameters by checking for the existence of 
objects and by verifying that the objects are of the proper types. You 
can exclude all parameter validation by Nucleus system calls from your 
application system by modifying the feature configuration table. To do 
this, replace the percent-sign (Z) in the ZPARAMETER_VALIDATION macro 
with a semicolon (;)* The Inclusion or exclusion of parameter validation 
by making modifications to NTABLE.A86 is called system-level 
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parameter validation* It must be noted, however, that parameter 
validation provides a very Important safeguard while developing software* 
If parameter validation Is not configured, erroneous parameters will go 
undetected until some undefined and possibly catastrophic result occurs* 

■ ■ ■ ■ . i ■■ 

If your system software includes the Ba^c I/O subsyste^ parai^te:ii 
validation should always be configured. J If your software does not include 
the Basic I/O subsystem, inclusion of system-level parameter validation 
can be helpful during development stages and exclusion of system-level 
parameter validation can be beneficial after development* 

Whether or not you include system-level parameter validation, you can als^ 
Include or. exclude parameter validation on a job-to-job basis with a/ 
parameter to the CREATE$JOB system call (refer to the IRMX 86 NUCLElp 
REFERENCE MANUAL for details)* If you have included the system-level 
support, the CREATE$JOB system call allows you include or exclude 
parameter validation support on an individual job basis* Table 6-1 shows 
the relationship' between system-level and job-level parameter validation 
support in terms of code savings and performance. 


Table 6-1. System-level and Job-level Parameter Validation 


System-level parameter | 
validation j 

Included 

Excluded 

Job-level parameter 
validation 

Included 

Excluded 

Included 

Excluded 

Is parameter validation 
performed for this job? 

yes 

no 

no 

no 

Does the system 
realize a code savings? 

no 

no 

yes 

yes 

Does the job realize 
a performance 
improvement? 

no 

yes 

yes 

yes 


System Default Exception Handlefi 

M 

If you do not modify NTABLE.A86, a system default exception handler is 
included in your system automatically* This exception handler deletes 
any task that causes an exceptional condition to occur* However, if you 
remove the %SYSTEM EXCEPTION_HANDLER macro from NTABLE.A86 by replacing, 
the percent-sign (X) with a semicolon (;), an alternate system exceptlo|i 
handler is included in your system*. This alternate handler suspends, 
rather than deletes, a task that causes an exceptional condition* 
Including this alternate system default exception handler could result in 
a significant code savings, if you are not otherwise using the 
DELETE$TASK system call* 
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SELECTING NUCLEUS SYSTEM CALLS 

Figure 6-3 shows the system call configuration table portion of NTABLE.A86. 
To exclude a system call from your application system, replace the percent- 
sign (Z) at the beginning of the corresponding macro with a semicolon (;)• 


%R0GETT1PE 

%rodtsabledeletion 

%RO£NaBLEOELEXION 

%R0CATAL0G0BJECT 

IROUNCATALOGOBJECT 

%R0L00KUP0RJECT 

AROCPtATEEXTENSION 

%rqoeleteextension 

%RQCREArECOMPOSITE 

%rqdeletecomposite 

%ROINSPECTCOMPOSITE 

%ROAl.rERCQMpOSlTE 

%R0F0RC£DELETE 

%KOCR£AfEJOB 

%rooelexejob 

%ROOFfSpRING 

%rocpeatetask 

%rodelexetask 

%rosuspendtask 

%R0RESUrtETA5K 

%R0SL£EP 

%kogettasktokens 

%ROGFIPRIORITY 

%R0SEXPRI0RITY 

%rocreatemailbox 

%RODEuEXENAILBOX 

^sROSENDMESSAGE 

%RQkECEIV£MESSAGE 

%RQCP£ATESEMAPH0RE 

%rqoelexesemaphore 

%R0SENDUNITS 

%RORECEiVEUNITS 

%ROCREATEREGION 

%rqoelexeregion 

%R05ENDC0NTR0L 

%R0RECEIVEC0NTR0L 

%KQACCEPTC0NTR0L 

%H0CREATE5EGMENT 

%R0DELETESEGMENT 

%rqgexsize 

%R0GEIP00LATTRIB 

%ROSETPOOL*MIN 

%RQSFXOSEXTENSION 

%R05EIINTERRUPT 

%R0ENXERINTERRUPT 


Figure 6-3. System Call Configuration Table (NTABLE.A86) 
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%roenable 

%ROOISABLE 

%roreseiinterrupt 

%ROGE:rLEVEL 

IROEXITINIERRUPT 

%ROSIGNALINTeRRUPT 

%R0«(AITINTERRUPT 

%rogfxexceptionhandler 

%rosftexceptionhandler 

%rosignalexception 


END 


Figure 6-3. System Call Configuration Table (NTABLE.A86) (continued) 


MODIFYING NDEVCF.A86 

NDEVCF.A86 consists of a series of macro calls that specify Information 
about the following components: 

• Programmable Interrupt Controller (PIC) 

• Programmable Interval Timer (PIT) 

• 8087 Numeric Data Processor (NDP) 

As released} NDEVCF.A86 describes a standard system consisting of a 
master 8259A PIC and an 8253 PIT. If your system varies from this 
configuration* or If you want to change the attributes of any of the 
conqjonents* you must modify NDEVCF.A86. Figure 6-4 Illustrates the 
component configuration portion of NDEVCF.A86. 


$INCr.UDE(:F2:NDEVCF.MAC) 

%MA5TER-PIC(R259A,0C0H,0,0) 

?SLAVE-PIC( SLAVE-TYPE, BASE-PORT, EDGE-VS-LEVEL , MASTER-LEVEL ) 
1TTMER(8253,0D0H,28H, 12288) 

?NDP-SUPPQRT( ENCODED-LEVEL ) 

END 


Figure 6-4. Coiq>onent Configuration Table (NDEVCF.A86) 
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The file m}£VGF«li&C, which is available on the Nucleus release diskette, 
contains the definitions of all macros called in NDEVCF.A86. NDEVCF.A86 
contains an $INCLUDE statement which includes NDEVCF.MAC in the assembly 
of NDEVCF.A86. 

The following sections describe modifying NDEVCF.A86 to include 
information about individual components. 


PROGRAMMABLE INTERRUPT CONTROLLER <PIC) CONFIGURATION 

The iRMX 86 Operating System supports a hardware environment with either 
a single PIC (non-cascaded mode) or several PICs (cascaded mode). Two 
macros are available to define the environment and the attributes of each 
PIC. These macros are: 

%MASTER_PIC 

%SLAVE_PIC 

The %MASTER_PIC macro defines the attributes of the master PIC. This 
macro is required for both cascaded and non-cascaded mode. The 
%SLAVE_PIC macro is required only in cascade mode and defines the 
attributes of a slave PIC. One %SLAVE_PIC macro is required for each 
slave PIC in the system. All %SLAVE_PIC macros must follow the 
%MASTER_PIC macro in NDEVCF.A86. The following sections describe the 
formats of the two macros. 


%MASTER_PIC Macro 

The %MASTER_PIC macro defines the attributes of the single PIC, when in a 
non-cascaded environment, or the master PIC, when in a cascaded 
environment. The format of this macro call is as follows: 

%MASTERJPIC(8259A, base_port, 0, 0) 

where: 

base_j)ort 

Port address of the master PIC. When using Intel processor boards 
such as the iSBC 86/12A and iSBC 86/05, you must specify a value of 
OCOH for this parameter. The Nucleus assumes that all ports are at 
even port addresses (base port + 0, base port +2, base port + 4, and 
so on). 

Because the Operating System currently supports only the 8259A PIC, you 
must specify the remaining parameters as shown. These remaining 
parameters are reserved for future support upgrades. For further 
information about the 8259A PIC, refer to THE 8086 FAMILY USER'S MANUAL. 

As released, NDEVCF.A86 contains a default %MASTER_PIC call that defines 
an 8259A PIC with a port address of OCOH. If your master PIC requires a 
different value, you must modify this call. 
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%SLAVEJPIC Macro 

The %SLAVEJPIC macro defines the attributes of a slave PIC In a cascaded 
environment* You must include one %SLAVE^PIC macro for each slave PIC in 
your system. All of these %SLAVE_PIC calls must follow the %MASTERJPIC 
call* The format of the %SLAVEJPIC call is as follows: 

%SLAVE_PIC(8259A, base^port, edge_ys_level, master^level) 

where: 

Port address of the slave PIC# The Nucleus assumes 
that all ports are at even port addresses (base port + 
0, base port + 2 , base port + 4, and so on). 

Triggering mode for the PIC# Specify this parameter 
as follows: 

value description 

0 Edge triggering mode 

nonzero Level triggering mode 

Interrupt level on the master PIC which connects 
to the slave PIC. You must specify a value in 
the range 0 through 7 for this parameter# 

Because the Operating System currently supports only the 8259A PIC, you 
must specify the remaining parameter as shown# This remaining parameter 
is reserved for future support upgrades* 

As released, NDEVCF.A86 does not Include a %SLAVE_PIC call# If your 
system includes multiple interrupt controllers in a cascaded environment, 
you must modify NDEVCF.A86 to include a %SLAVE_PIC call for each slave 
PIC# 


base^port 


edge_ys_level 


master level 


PROGRAMMABLE INTERVAL TIMER (PIT) CONFIGURATION 

You can specify the attributes of the PIT by calling the %TIMER macro* 
The format of this macro call is as follows: 

%TIMER(8253, bas export, level, count) 
where: 

base_j)ort Port address of the PIT# When using Intel processor 

boards such as the iSBC 86/12A and iSBC 86/05, you 
must specify a value of ODOH for this parameter* The 
Nucleus assumes that all ports are at even port 
addresses (base port + 0, base port +. 2, base port + 
4, and so on). 
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level Encoded value specifying the interrupt level of the 

master PIC to which this timer is connected. This value 
corresponds to the interrupt levels as follows: 

value level 

x8H Master levels MO through M7 

(0 > X > 7) 

count Down count value that is loaded into the timer 

register* You should use the following formula to 
determine this value: 

count = tick X clock__f requency 

where: 

tick* The period of time, in milliseconds, 

that you wish to specify as a clock 
interval. 

clock__ The frequency, in kilohertz, of the 
frequency clock input to the timer. 

Because the Operating System currently supports only the 8253 PIT, the 
remaining parameter must be specified as shown. This remaining parameter 
is reserved for future support upgrades. For further information 
concerning the 8253 PIT, refer to THE 8086 FAMILY USER’S MANUAL. 

As released, NDEVCF.A86 contains a default %TIMER call which specifies a 
port address of ODOH, an interrupt level of 2, and a 1.2288 megahertz clock 
with 10 millisecond clock interval. If your system requires a different 
specification, you must modify NDEVCF.A86. 

The standard clock interval for the iRMX 86 Operating System is 10 milli- 
seconds* Unless an application requires a different value, it is highly 
recommended that this standard value be used. This will Insure that pro- 
grams using timed wait operations will be portable between iRMX 86 systems. 


8087 NDP CONFIGURATION 

If your system contains an 8087 NDP, you must call the %NDP^SUPP0RT macro. 
This macro sets up a system interrupt handler for the NDP and associates it 
with a specified Programmable Interrupt Controller. The format of the 
macro call is as follows: 

%NDP_SUPP0RT ( le ve 1 ) 

where: 

level Encoded value specifying the interrupt level connected 

to the 8087 NDP interrupt pin* This value corresponds 
to the interrupt level as follows: 
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value 


level 


x8H 

(0 > X > 7) 


Master Interrupt levels MO through 
M7. 


yzH Slave interrupt levels 00 through 

(0 > y > 7) 77. 

(0 > 2 > 7) 


No other application code can make use of this 
interrupt level. Also, any task which uses the 8087 
NDP must not have a priority high enough to mask this 
interrupt level. Master level zero is recommended. 
Refer to the iRMX 86 NUCLEUS REFERENCE MANUAL for 
information concerning interrupt levels and priorities. 


As released, NDEVCF.A86 does not include the %NDP_SUPPORT macro call. If 
your system contains an 8087 NDP, you must modify NDEVCF.A86 to include 
the %NDP_SUPPORT call. 

For further information about the 8087 NDP, refer to THE 8086 FAMILY 
USER'S MANUAL, NUMERICS SUPPLEMENT. 


MAXIMAL, DEFAULT, AND MINIMAL CONFIGURATION 

The maximal Nucleus configuration (for features and system calls) 
consists of all supported Nucleus system calls, parameter validation, and 
the system default exception handler. This maximal configuration is the 
same as the default configuration. You do not need to modify NTABLE.A86 
in order to obtain this maximal configuration. 

The default component configuration defines the attributes of the 
components as they exist on the iSBC 86/12A single board computer. 

The minimal Nucleus configuration for a Nucleus-only application system 
consists of no configurable Internal features and only the following 
system calls: 

CREATE$J0B 

SUSPEND$TASK 

RESUME$TASK 

GET$TASK$T0KENS 

SIGNAL$EXCEPTI0N 

You must always Include these system calls in your application system. 

You can, of course, include any or all other system calls and internal 
features that your application system requires. 
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ASSEMBLING THE CONFIGURATION FILES. LINKING AND LOCATING THE NUCLEUS 


After you have made any necessary modifications to the Nucleus 
configuration files, NTABLE.A86 and NDEVCF.A86, you must assemble them 
and link and locate the Nucleus. NUCLUS.CSD, a SUBMIT file contained on 
the Nucleus release diskette, can be used to perform these functions. In 
order to use this SUBMIT file, you must first prepare your diskettes and 
place them in the proper drives of your development system as explained 
in the "Linking and Locating the Subsystems" section of Chapter A, You 
should also examine NTABLE.A86 and NDEVCF.A86 to make sure that the 
$INCLUDE statements contain the proper disk identifiers. Then you can 
enter the following command: 

SUBMIT :fx:NUCLUS(date, loc adr) 


where: 


fx 

The appropriate disk identifier, indicating the drive 
containing NUCLUS.CSD. 

date 

The date on which you submit the file (maximum of nine 
characters). 

loc_adr 

The address at which to locate the Nucleus. If you 
want to enter this value as a hexidecimal number, you 
must include the suffix H. 


This command assembles NTABLE.A86 and NDEVCF.A86, links them together 
with other libraries that contain the Nucleus code and locates the 
Nucleus at the specified address. It places the located Nucleus in file 
NUCLUS on drive FI. It also places the assembly listings, link map, and 
locate map on drive F3 in files NTABLE.LST, NDEVCE.LST, NUCLUS. MPl, and 
NUCLUS .MP2, respectively. 


NOTE 

The link map for the Nucleus always 
contains a warning message indicating a 
possible overlap. This is a normal 
message for the Nucleus. It does not 
indicate an error in the LINK86 command. 


NUCLEUS INITIALIZATION ERRORS 


If the Nucleus encounters an error during the initialization process, it 
places diagnostic information in the processor registers and halts the 
processor. Errors can occur during two operations: 

Nucleus and memory initialization 

Job creation by the root task 
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The value placed In the AX register determines which type of error 
occurred* The following sections outline these errors* 


NUCLEUS AND MEMORY INITIALIZATION ERRORS 


If an error occurs during the Nucleus and memory Initialization process, 
the Nucleus sets the processor registers as follows: 

register value description 


AX 


BX 


IIH A Nucleus or memory Initialization 

error occured* "nte BX register 
contains a description of the error* 

ODOOIH There are no SABs defined* There must 

be at least one* 


0D002H 


The interrupt vector is not contained 
in a SAB* 


0D003H 


Reserved* 


0D004H 


0D005H 

0D006H 

0D007H 


There is not enough contiguous RAM 
available for the root job's memory 
pool* 

The SABs are out of order or overlap* 

There is not enough RAM available for 
the system resources of the Nucleus* 

An invalid minimum transfer size was 
specified in the %SYSTEM macro* Refer 
to the ”%SYSTEM Macro” section of 
Chapter 4 for a description of the 
minimum transfer size* 


ROOT TASK ERRORS 

If the root task encounters an error while it is creating the first-level 
jobs of your application system, it sets the processor registers as 
follows: 

register value description 

AX 21H A root task error occurred* The BX, 

CX, and DL registers contain a 
description of the error* 
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register value 


BX 


varies 


CX 


varies 


DL 


varies 


description 

BX is set as an index to indicate which 
%JOB call in the system configuration 
file caused the error. For example, 1 
implies the first %JOB call in the 
file, 2 the second, and so forth. 

CX contains the exception code returned 
from the CREATE$JOB system call that 
was called to create the first-level 
job. 

DL contains the number of the parameter 
in the %JOB call that caused the 
error. If DL is greater than 8, the 
parameter number is DL +1. Otherwise, 
the parameter number is DL. 
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CHAPTER 7. CONFIGURING THE TERMINAL HANDLER 


The Terminal Handler provides real-time, asynchronous I/O between an 
operator terminal and tasks running under the iRMX 86 Operating System. 

Terminal Handler configuration Involves selecting characteristics of the 
Terminal Handler and specifying information about the processor board and 
the terminal. You perform these operations by making modifications to an 
Intel-supplied Terminal Handler configuration file. This file, 

MC0NFG.A86, is an assembly language source file which is contained on the 
Terminal Handler release diskette. 

As released, MC0NFG.A86 defines a Terminal Handler that communicates with 
a 9600 baud terminal and runs on an iSBC 86/12A single board conq>uter. -y ^ 

If you want the Terminal Handler to run on a different hardware 

configuration, or if you want to change some of the characteristics ©f^^^ ^ 

the Terminal Handler, you must modify MCONFG.A86, assemble it, link it 

with the rest of the Terminal Handler object files and libraries, and xntx 1^0 

locate the Terminal Handler at an absolute address. The following 

sections discuss this configuration process in detail. 


MODIFYING MC0NFG.A86 


MC0NFG.A86 can consist of a series of macro calls which identify the 
characteristics of the Terminal Handler, the terminal, and the processor 
board. Figure 7-1 illustrates the released MCONFG.A86. As you can see 
by this figure, the released file contains only an $INCLUDE statement. 
This $INCLUDE statement causes the Terminal Handler to be assembled with 
the default configuration parameters. To change the configuration, you 
must add macro calls to MCONFG.A86. MCONFG.A86 can contain calls to the 
following macros: 

%TH_1 9200_BAUD_COUNT 
%MTH 

%TH_INT_LEVELS 
%TH_USART 
%TH_TIMER 
%TH_CHAR_LENGTH 
%TH_MAILBOX_NAME S 

The file MTHCNF.MAC, which is available on the Terminal Handler release 
diskette, contains the definitions of all these macros. MCONFG.A86 
contains an $INCLUDE statement for MTHCNF.MAC, which includes it in the 
assembly of MCONFG.A86. 

The following sections describe the macro calls in detail. 
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*lnclude( :f2:t»tncnf .mac) 
end 


Figure 7-1. Terminal Handler Configuration File (MCONFG.A86) 


rrH_19200_BAUD_C0UNT MACRO 

If your system's programmable Interval timer (PIT) has a clock Input 
frequency other than 1.2288 megahertz, you must call this macro to set 
the limits on the baud rate attributes of the Terminal Handler. The 
format of the call to this macro Is as follows: 

ZTH_1 9200_BAUD_COUNT( count ) 
where; 

count Value that when loaded Into the timer register 

generates a maximum baud rate of 19200. The value 
that you enter for this parameter depends on the clock 
Input frequency to your system's PIT (refer to the 
following paragraphs). If you do not Include the 
macro call, a default value of 4 Is assumed, which 
corresponds to the default frequency of the clock 
Input to the 8253 PIT on the ISBC 86/12A board. 

To derive the value to use for the count parameter, you must first 
determine the clock Input frequency to the PIT (In hertz). Then 
substitute this frequency Into the following equation: 

(1) result ■ (clock frequency In hertz) / (19200 X 16) 

Then substitute "result" from equation 1 Into the following equation: 

(2) fraction result - INT(result) 

where INT(result) Is rfn Integer obtained by truncating the fractional 
portion of "result". If "fraction" from equation 2 Is greater than or 
equal to 0.5, then: 

(3) count ■ INT(result) + 1 

error fraction * 1.0 - fraction 
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If "fraction" is less than 0.5, then: 

(4) count “ INT(result) 
error_fraction = fraction 

Before placing "count” from equation 3 or 4 Into the %TH_19200_BAUD_C0UNT 
call, you should first determine the percentage of error in this value. 
You do this by solving the following equation: 

(5) % error = (error_fraction / count) X 100 

If the percentage of error is less than 3%, you can use any Terminal 
Handler-supported baud rate (which you later specify in the %MTH macro, 
described later in this chapter). However, if the percentage of error is 
3% or greater, you will have to perform the following additional 
computations. 

First, determine the desired baud rate of the terminal. Substitute this 
value for the 19200 in equation 1 and recompute the value of "count" 
(equations 1 through 4). Again determine the percentage of error 
(equation 5). If the error is less than 3% with the new baud rate, you 
can use the Terminal Handler with that new baud rate (and specify it in 
the %MTH macro)* However, if the percentage of error is still 3% or 
greater, the combination of desired baud rate and clock frequency is 
unacceptable to the Terminal Handler. You will have to change one or the 
other. After doing this, recompute the error to verify that it falls 
below the 3% level. 

Regardless of the baud rate you eventually choose, use the "count" value 
as originally computated (with the 19200 value) as input to the 
%TH_19200_BAUD_COUNT macro call. 

If MCONFG.A86 does not contain a call to the %TH_19200_BAUD_COUNT macro, 
the Terminal Handler will operate as if you had specified this macro call 
with a value of 4 for the count parameter. This is an appropriate value 
for the default input frequency to the 8253 PIT on the iSBC 86/12A board 
(or any timer with an input frequency of 1.2288 megahertz). 

If you specify this macro call, you must place it as the first macro call 
in MC0NFG.A86. 


XMTH MACRO 

This macro allows you to designate the baud rate and rubout 
charateristics of your terminal. The format of this macro is as follows: 

%MTH (baud_rate, rubout_mode, blank_char) 

where: 
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baud_rate Baud rate of the terminal being used with the Terminal 

Handler* Specify one of the following rates: 

19200 

9600 

4800 

2400 

1200 

600 

300 

150 

110 

Refer to the "%TH_19200_BAUD_C0UNT Macro" section of 
this chapter to ensure that the value you enter for 
this parameter will cause the Terminal Handler to 
operate correctly. If you omit the macro call, a 
default value of 9600 is assumed. 

rubout_mode Terminal Handler rubout mode. Enter one of the 
following: 

1 The Terminal Handler echoes the deleted 
character back to the terminal. 

2 The Terminal Handler replaces the deleted 
character with the blank character. 

If you omit the macro call, a default value of 2 is 
assumed. 

blank_char Blanking character for use with option 2 of 

rubout_mode. If you omit the macro call, the default 
blanking character Is assumed to be the ASCII space 
(020H). 

If MC0NFG.A86 does not contain the %MTH call, the Terminal Handler 
assumes a 9600 baud terminal with blanking mode 2 and a blanking 
character of ASCII space (020H). 


%TH_USART MACRO 

This macro allows you to designate the port address of the USART. The 
format of this macro call Is as follows: 

%THJJSART( base_por t ) 
where: 

base_port Hexadecimal number specifying the base port address of 

the USART. The Terminal Handler assumes that all 
ports are at even port addresses (base port + 0, base 
port + 2, base port + 4, and so on). If you omit the 
macro call, a value of 0D8H Is assumed. 
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If MCONFG.A86 does not include a call to %THJJSART, the Terminal Handler 
assumes a USART port address of 0D8H. This value must be used for Intel 
processor boards, such as the iSBC 86/12A and iSBC 86/05 single board 
computers. 


%THJTIMER MACRO 

This macro allows you to specify information about the programmable 
interval timer (PIT). The format of the macro call is as follows: 

%TH_TIMER(ba seaport, baud_counter ) 
where: 

base^port Port address of the PIT. The Terminal Handler assumes 

that all ports are at even port addresses (base port + 
0, base port + 2, base port + 4, and so on). If you 
omit the macro call, a value of ODOH is assumed. 

baud__counter Number of the PIT counter connected to the USART clock 
input The output of this counter generates the 
Terminal Handler baud rate. You must specify a value 
from 0 to 2 for this parameter. If you omit the macro 
call, a value of 2 is assumed. You must ensure that 
the counter you select is not used by the Nucleus or 
any other module. The Nucleus uses counters 0 and 1 
of the timer to which it is connected. Therefore, if 
your system does not contain an off-board timer, you 
must use counter 2 for the Terminal Handler. 

If MCONFG.A86 does not contain the %TH_TIMER macro call, the Terminal 
Handler operates as if you had specified this macro call with a value of 
ODOH for the base^port parameter and a value of 2 for the baud^counter 
parameter. These values must be used for Intel processor boards, such as 
the iSBC 86/12A and iSBC 86/05 single board computers. 


%TH_CHAR_LENGTH MACRO 

This macro allows you to specify the number of bits of valid data per 
character sent from the USART. The format of this macro call is as 
follows: 


%TH_CHAR_LENGTH( length ) 
where: 


length 


Number of bits of valid data per character sent from 
the USART. The only acceptable values for this 
parameter are 7 and 8. If you omit the macro call, a 
value of 7 is assumed. 
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If MCONFG.A86 does not contain the %TH_CHAR_LENGTH macro, the Terminal 
Handler assumes 7 bit characters, which is appropriate for systems using 
the ASCII character set. 


%TH_MAILBOX_NAMES MACRO 

This macro allows you to specify names for the Terminal Handler's input 
and output mailboxes. The format for this macro call is as follows; 

%TH _MAILBOX_NAMES(lnput_mailbox, output_mailbox) 

where: 


input_mallbox 


Name of the mailbox used for input to the Terminal 
Handler. Legitimate names consist of 12 or less 
alphanumeric characters. If you omit the macro call, 
the name RQTHNORMIN is assumed. 


output_mallbox Name of the mailbox used for output by the Terminal 
Handler. Legitimate names consist of 12 or less 
alphanumeric characters. If you omit the macro call, 
the name RQTHNORMOUT is assun^d. 

If MC0NFG.A86 does not contain the %TH_MAILBOX_NAMES macro call, the 
Terminal Handler uses the names RQTHNORMIN and RQTHNORMOUT for its input 
and output mailboxes. 



If you intend to use the Basic I/O System's On Board USART driver to 
communicate with the Terminal Handler, you must provide a Terminal 
Handler whose input and output mailboxes have the names RQTHNORMIN and 
RQTHNORMOUT, respectively. The Basic I/O System will communicate only 
with a Terminal Handler that uses these mailbox names. 


%TH_INT_LEVELS MACRO 

This macro allows you to specify the interrupt levels used by the 
Terminal Handler for input and output. The format of the call to this 
macro is as follows: 

%TH_INT_LEVELS(input_level, output_level) 
where: 

lnput_level Encoded value specifying the interrupt level used for 
input to the Terminal Handler. This value corresponds 
to the Interrupt level as follows: 

value level 

x8H Master interrupt levels MO through 

(0 > X > 7) M7. 
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value level 

yzH Slave Interrupt levels 00 through 

(0 > y > 7) 77. 

(0 > z 7 7) 

If you omit the macro call, a value of 68H Is assumed. 

output_level Encoded value specifying the interrupt level used for 
output by the Terminal Handler. This value 
corresponds 

value 


x8H 
(0 > X 

yzH 
(0 > y 
(0 > z 

If you omit 

The Input Interrupt level must 
interrupt level. The IRMX 86 NUCLEUS REFERENCE MANUAL describes the 
relationship between interrupt levels and priorities. 

The maximum priority of user tasks in an application system containing 
the Terminal Handler depends on the interrupt levels assigned to the 
Terminal Handler with the %TH_INT_LEVELS macro. The priorities of all 
user tasks must be lower (numerically higher) than the lowest priority 
interrupt task in the Terminal Handler. In the default configuration, 
the Terminal Handler's output interrupt level is set to M7, which 
corresponds to a priority of 130 for the output Interrupt task. Thus, 
with the default Terminal Handler configuration, all user tasks must have 
a priority lower (numerically higher) than 130. 

If MC0NFG.A86 does not contain the %TH_INT_LEVELS macro call, the 
Terminal Handler assumes master level M6 (68H) for input and master level 
M7 (78H) for output. 


to the Interrupt level as follows: 
level 

Master interrupt levels MO through 

> 7) M7. 

Slave Interrupt levels 00 through 

> 7) 77. 

> 7 ) 

the macro call, a value of 78H is assumed, 
be a higher priority level than the output 




ASSEMBLING MC0NFG.A86, LINKING AND LOCATING THE TERMINAL HANDLER 

MTH.CSD, a SUBMIT file contained on the Terminal Handler release 
diskette, can be used to assemble MCONFG.A86 and link and locate the 
Terminal Handler. In order to use this SUBMIT file, you must first 
prepare your diskettes and place them in the proper drives of your 
development system as explained in the "Linking and Locating the 
Subsystems" section of Chapter 4. You may also have to make 
modifications to MTH.CSD before submitting it, depending on your Terminal 
Handler requirements* This section describes MTH.CSD modifications and 
the format of the command to submit this file. 
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MTH.CSD MODIFICATIONS 

If you are providing code to implement control-C semantics, you must 
place this code in a procedure named RQABORTAP, which uses only near 
calls. Since this procedure runs as part of the interrupt task for the 
Terminal Handler, which does not have an exception handler, it should not 
make any system calls to delete its task, delete its job, suspend its 
task, or change its priority. The environmental condition codes 
generated as a result of making these system calls are returned in-line. 
Assemble this procedure and modify MTH.CSD to place its object file name 
in the LINK86 input list immediately after MCONFG.OBJ. Refer to the IRMX 
86 TERMINAL HANDLER REFERENCE MANUAL for further information on the 
default control-C semantics. 

The Human Interface release diskette Includes a library HI. LIB which 
contains a module HCONTC that implements control-C semantics for the 
Human Interface. If you are planning to include the Human Interface in 
your application system and wish Include the control-C features of the 
Human Interface, you must link this module in with the Terminal Handler 
through which the Human Interface communicates. Include the following 
line in the LINK86 input list immediately after MCONFG.OBJ: 

:fx:HI.LIB(HCONTC), & 

This module should replace any control-C semantics files that you would 
otherwise Include. 


SUBMITTING MTH.CSD 

Enter the following command to assemble MC0NFG.A86 and link and locate 
the Terminal Handler: 

SUBMIT :fx:MTH(date, loc _adr, type) 


where : 

fx The appropriate disk identifier, indicating the drive 

containing MTH.CSD. 

date The date on which you submit the file (maximum of nine 

characters). 

loc _adr The address at which to locate the Terminal Handler. 

If you want to enter this value as a hexadecimal 
number, you must Includd the suffix H. The base 
portion of this value is the base portion of the 
Terminal Handler's entry point. The offset portion of 
the entry point is 0. You must specify this entry 
point in the %J0B macro call for the Terminal Handler. 
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type Type of Terminal Handler you wish to create. Enter 

one of the following: 

RQOUTPUT An output-only version of the 
Terminal Handler is generated. 

RQINPUT An input and output version of the 
Terminal Handler is generated. 

This command assembles MC0NFG.A86, links it together with other modules 
that contain Terminal Handler code, and locates the Teminal Handler at 
the specified address. It places the located Terminal Handler in file 
MTH on drive FI. It also places link and locate maps on drive F3 in 
files MTH.MPl and MTH.MP2 respectively. 

You must specify a %JOB macro in the system configuration file for the 
Terminal Handler (refer to Chapter 4)* In this macro, the entry point 
depends on the address at which you locate the Terminal Handler (CS:0). 
The data segment base should be specified as 0 (the Terminal Handler 
assigns its own data segment). 


CREATING MULTIPLE VERSIONS OF THE TERMINAL HANDLER 


If desired, your IRMX 86 system can contain multiple versions of the 
Terminal Handler. This may be desirable if, for example, you have two 
tasks that use the Terminal Handler and you want to communicate with 
these tasks from separate terminals. In order to create multiple 
versions of the Terminal Handler, you must obey the following rules: 

• Each Terminal Handler must use different input and output mailbox 
names. That is, the %TH_MAILBOX_NAMES calls must be different. 

• Each Terminal Handler must use a unique USART. This also means 
that the %TH_USART calls must be different. 

• Each Terminal Handler must use a unique timer. This also means 
that the %TH_TIMER calls must be different. 

• Each Terminal Handler must use different interrupt levels. This 
also means that the %TH_INT^EVELS calls must be different. 

• The code for the Terminal Handlers must be located in different, 
non*^ver lapping areas; each Terminal Handler must have its own 
data area. 

• Each Terminal Handler must have its own %JOB macro in the system 
configuration file. 

If you adhere to these rules, you can create multiple versions of the 
Terminal Handler in your application system. 
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Because the Debugger contains a copy of the Terminal Handler, Debugger 
configuration Is almost Identical to Terminal Handler configuration 
(except that only one Debugger can be present In the application 
system)* Debugger configuration Involves selecting characteristics of 
the Debugger's Terminal Handler and specifying Information about the 
processor board and the terminal* You perform these operations by making 
modifications to an Intel-supplied Debugger configuration file* This 
file, DTHCNF*A86, Is an assembly language source file which Is contained 
on the Debugger release diskette. 

As released, DTHCNF.A86 defines a Terminal Handler for the Debugger that 
communicates with a 9600 baud terminal and runs on a system that uses an 
ISBC 86/12A single board computer* If you want the Debugger's Terminal 
Handler to run on a different hardware configuration, or If you want to 
change some of the characteristics of that Terminal Handler, you must 
modify DTHCNF.A86, assemble It, link It with the rest of the Debugger 
object files and libraries, and locate the Debugger at an absolute 
address* The following sections discuss this configuration process In 
detail* 


MODIFYING DTHCNF.A86 

DTHCNF.A86 can consist of a series of macro calls which Identify the 
characteristics of the Debugger's Terminal Handler, the terminal, and the 
processor board* Figure 8-1 Illustrates the released DTHCNF.A86, which 
causes the Debugger to be assembled with default configuration 
parameters* To modify this file, refer to the "Modifying MCONFG.A86" 
section of Chapter 7* The macro calls that you can place In DTHCNF.A86 
are exactly the same as those described In Chapter 7* 


$lnclude(:fl:dthcnf,ipac) 

end 


Figure 8-1* Debugger Configuration File (DTHCNF.A86) 
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ASSEMBLING DTHCNF.A86, LINKING AND LOCATING THE DEBUGGER 

DB.CSD, a SUBMIT file contained on the Debugger release diskette, can be 
used to assemble DTHCNF«A86 and link and locate the Debugger. In order 
to use this SUBMIT file, you must first prepare your diskettes and place 
them in the proper drives of your development system, as explained in the 
"Linking and Locating the Subsystems" section of Chapter 4. You may also 
have to make modifications to DB.CSD before submitting it, depending on 
your Debugger requirements. This section discusses DB.CSD modifications 
and the format of the command to submit this file. 


DB.CSD MODIFICATIONS 

If you are providing code to implement control-C semantics, you must 
place this code in a procedure named RQABORTAP, which uses only near 
calls. Since this procedure runs as part of the interrupt task for the 
Terminal Handler, which does not have an exception handler, it should not 
make any system calls to delete its task, delete its job, suspend its 
task, or change its priority. The environmental condition codes 
generated as a result of making these system calls are returned in-line. 
Assemble this procedure and modify DB.CSD to place its object file name 
in the LINK86 input list Immediately after DTHCNF.OBJ. Refer to the IRMX 
86 TERMINAL HANDLER REFERENCE MANUAL for further information on the 
default control-C semantics. 

The Human Interface release diskette Includes a library HI. LIB which 
contains a module HCONTC that implements control-C semantics for the 
Human Interface. If you are planning to Include the Human Interface in 
your application system and wish include the control-C features of the 
Human Interface, you must link this module in with the Terminal Handler 
with which the Human Interface communicates. If the Human Interface 
communicates with the Debugger's Terminal Handler, you must link this 
module in with the Debugger. To do this, include the following line in 
the LINK86 input list Immediately after MCONFG.OBJ: 

:fx;HI.LIB(HCONTC), & 

This module should replace any control-C semantics files that you would 
otherwise include. 


SUBMITTING DB.CSD 

Enter the following command to link and locate the Debugger; 

SUBMIT ;fx;DB(date, loc_adr) 
where; 


fx 


The appropriate disk Identifier, indicating the 
drive containing DB.CSD. 



CONFIGURING THE DEBUGCTIR 


date The date on which you submit the file (maximum 

of nine characters). 

loc_adr The address at which to locate the Debugger. If 

you want to enter this value as a hexadecimal 
number, you must Include the suffix H. The base 
portion of this value is the base portion of the 
Debugger's entry point. The offset portion of 
the entry point is 0. You must specify the 
entry point in the %J0B macro call for the 
Debugger. 

This command links together the modules that make up the Debugger and 
locates the Debugger at the specified address. It places the located 
Debugger in file DB on drive Fl. It also places the link and locate maps 
on drive F3 in files DB.MPl and DB.MP2 respectively. 

You must specify a %J0B macro in the system configuration file for the 
Debugger (refer to Chapter 4). In this macro, the entry point depends on 
the address at which you locate the Debugger (CS:0). The data segment 
base should be specified as 0 (the Debugger assigns its own data 
segment). The exception_handler mode must be specified as 0. 
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CHAPTER 9. CONFIGURING THE BASIC I/O SYSTEM 


Basic I/O System configuration Involves the following two operations: 

• Selecting the features and system calls of the Basic I/O System 
that you want to Include in your application system and 
discarding those that you do not want. 

• Supplying the Basic I/O System with Information about the I/O 
devices on your system. 


You perform both of these operations by making modifications to two 
Intel-supplied Basic I/O System configuration file: ITABLE.A86 and 
IDEVCF.A86. These files, which are contained on the Basic I/O System 
release diskette, are assembly language source files. They contain the 
following information: 

ITABLE.A86 This file contains information about the Interfaces 

available with the Basic I/O System, the individual 
system calls associated with each Interface, and the 
Internal features of the Basic I/O System. As 
released, ITABLE.A86 defines the full conq>lement of 
system calls and Internal features. 

IDEVCF.A86 This file contains a description of the devices 

supported, along with device and unit information for 
each supported device. As released, IDEVCF.A86 
describes a number of commonly available devices. 

Figure 9-1 Illustrates the structure of these two files. 
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NON-FiLE/CONNECTION 

INTERFACE 


FILE/CONNECTiON 

INTERFACE 


DESCRIBING 
I/O DEVICES 



Figure 9-1. ITABLE.A86 and IDEVCF.A86 Structure 


9-2 



















CONFIGURING THE BASIC I/O SYSTEM 


The following sections of this chapter show how to modify ITABLE.A86 and 
IDEVCF*A86 in order to produce a Basic I/O System that supports your 
individual needs* They also show how to assemble this file and link and 
locate the Basic I/O System. Some of the sections in this chapter list 
selected portions of the configuration file in order to aid you in the 
configuration process. 


INCLUDE FILES 


ITABLE.A86 must contain an $INCLUDE statement for the following file as 
the first statement (other than comments or general controls such as 
$TITLE) in the configuration file. 

ITABLE.INC This file contains segment, structure, macro, and 

miscellaneous definitions for the non-f ile/connect ion 
interfaces, the file /connect ion interface, file drlwr 
global data, and internal feature configuration. 

IDEVCF.A86 must contain an $INCLUDE statement for the following file as 
the first statement (other than comments or general controls such as 
$TITLE) in the configuration file. 

IDEVCF.INC This file contains segment, structure, and macro 

definitions for device driver configuration; structure 
definitions for device configuration; and the 
definition of the %DEVICE_TABLES macro. This macro is 
described in the "General Device Information" section 
of this chapter. 

These files are contained on the Basic I/O System release diskette. As 
released, ITABLE.A86 and IDEVCF.A86 contain $INCLUDE statements for these 
files. However, you should examine ITABLE.A86 and IDEVCF.A86 to ensure 
that the $INCLUDE statements contain the correct disk identifiers. 


SELECTING NON~FILE/CONNECTION INTERFACE FEATURES (ITABLE.A86) 
The non-file /connection interfaces consist of the following: 


parameter interface This interface supplies local parameters 

which the Basic I/O System uses each time 
a task makes a Basic I/O System call. 


configuration interface This interface is used by Operating System 

extensions to dynamically configure the 
Basic I/O System. 

power-fail interface This interface informs the Basic I/O 

System of impending power failure or power 
available conditions. 
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date/time Interface This Interface supplies date and time 

information. 


In ITABLE.A86, each non-file /connect ion interface consists of a group of 
related system calls. Figure 9-2 contains the portion of ITABLE.A86 that 
defines the non-f lle/connection interfaces. This code consists of macro 
calls which correspond in name to system calls. Each macro gives 
directions to the assembler to include the code for the corresponding 
system call in the Basic I/O System. 

If you do not modify this portion of ITABLE.A86, all of the system calls 
associated with the non-file /connection interfaces will be included in 
your application system. In order to exclude a system call from one of 
the non-f lle/connection interfaces, delete the metacharacter of the 
associated macro call (%), and replace it with the comment character 
(;). By doing this, you change the macro call into a comment and prevent 
the assembler from evaluating it. Any or all of the system calls shown 
in Figure 9-2 can be excluded in this manner. 


name liable 


$include(:fl:itabie.lncj 

seject 




Non-File-Connection Interfaces 




9 9 0 9 9 




Parameter Interface; 

%ro_create-user 
frq»inspect.user 
f ro-delete.user 
f ro.se t .default _user 
%rq.oet.def auit.user 
t ro. set.de f auit.prefl X 
%rq_qet.def auit.oreflx 

Configuration Interface; 

trq.a.onys tea l.a ttach.de vice 
%rq.a.pn vs I cai.de tach.de vice 


Figure 9-2. Non-File /Connect ion Interface Configuration Values 
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Power-Fall interface: 

%ra«DOwer.<3own 

%ra«oower_up 

Time interface: 

%rq_set«time 

%ra-Qet.time 


Figure 9-2. Non-File Connection Interface Configuration Values 

(continued) 


SELECTING THE FILE/CONNECTION INTERFACE FEATURES (ITABLE.A86) 


The file /connect ion interface is the primary programmatic Interface to 
the Basic I/O System, through which jobs manipulate connections and 
perform I/O. It provides the support for the file types available to the 
Basic I/O System user: named files, stream files, and physical files. 

This support is in the form of a file driver for each of these file types. 

ITABLE.A86 contains information about all of the file drivers supplied 
with the Basic I/O System. If you do not modify ITABLE.A86, all of the 
system calls associated with the file/connection interface will be 
Included in your application system. By modifying this file, you can 
eliminate entire file drivers or change the number of system calls 
supported by each driver. 1TABLE.A86 contains two types of data 
pertaining to file drivers. 

• File driver global data 

• File driver tables 

The following sections discuss how to modify this data in order to 
provide appropriate file driver support for your system. 


FILE DRIVER GLOBAL DATA 

The file driver global data consists of a group of macro calls which 
provide parameters used by all file drivers In your Basic I/O System. 
Figure 9-3 Illustrates the portion of 1TABLE.A86 which contains this 
global data. The values shown in this figure are contained In the 
released version of 1TABLE.A86 and are the suggested defaults* 
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; Define file-driver global data 

f 


%num-file.d rivers (4) 
%attach.devlce«t^»sk„prlo(129 ) 
%tliner-task«prlo(129) 


Figure 9-3. File Driver Global Data Parameters 


The following paragraphs discuss each of the macros shown In Figure 9-3. 
You can change the parameters of these macro calls from their default 
settings In order to reflect your Individual Basic I/O System 
requirements. 

ZNUM _FILE_DRIVERS This macro declares the number of file 

drivers In your Basic I/O System. 
Associated with each file driver Is a file 
driver number. Use the largest file 
driver number In your system as the value 
for this parameter. Intel-supplied file 
drivers are numbered as follows: 


di Iver number 


Physical files 1 
Stream files 2 
Named files 4 


ZATTACH_DEVICE_TASK_PRIO This macro declares the priority of the 

attach-devlce task. This task receives 
all requests to attach devices (via 
PHYSICAL$ATTACH$DEVICE). When the 
attach^evlce task receives such a 
request > It creates another task which 
actually handles the request. The second 
task's priority Is one less than the 
priority of the task which called 
PHYSICAL$ATTACH$DEVICE. Thus the second 
task has a slightly higher priority. 
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This macro declares the priority of the 
timer task. This task manages the 
time-of-day clock for the Basic I/O 
System. Its priority can impact its 
performance and the Basic I/O System 
behavior. If the priority is set too low, 
the timer task may not get to run as often 
as it needs and the clock will slip. If 
the priority is set too high, the timer 
task may take machine cycles away from 
high priority tasks. 


Associated with each file driver are two tables of procedure entry points 
and a macro call, which define the contents of the file driver. 

ITABLE.A86 contains this information for each of the Intel-supplied file 
drivers: the physical, stream, and named file drivers. 

The macro, named %FILE_DRIVER_INFO, supplies parameters that are of use 
to the particular file driver. This manual does not define these 
parameters; therefore you should not modify any of the macro calls unless 
you are excluding an entire file driver (discussed later in this section). 

One of the tables, the request table, lists the entry points of the 
procedures directly associated with the system calls of that file driver 
(for example, the REQREAD procedure is associated with the A$READ system 
call). These routines are called by user tasks. 

The other table, the I/O service (or ios) table, lists the entry points 
of procedures that are ultimately called to service requests generated by 
procedures in the request table. The procedures in an ios table are 
called by Basic I/O System routines. 

ITABLE.A86 provides the request tables and the ios tables in the form of 
two assembly language structures, REQ_FILE_DRIVER and IOS_FILE_DRIVER. 

The REQ_FILE_DRIVER structure defines the request table and the 
IOS_FILE_DRIVER table defines the ios table. The definitions for these 
structures are contained in the file ITABLE.INC, which is available on 
the Basic I/O System release diskette. The configuration file contains 
an $INCLUDE statement for this file, which includes it in the assembly of 
the configuration file. 

Figure 9-4 shows the portion of ITABLE.A86 that contains the 
%FILE_DRIVER_INFO call, the request table, and the ios table for the 
physical file driver. 


%TIMER TASK FRIO 


FILE DRIVER TABLES 
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9 9j9$$f9»9099§^$r99§9§999§9§09r99f999f 9 09 0Pf9§f9^ 9 t$999$f9f$9$999§t9 


Pfiyslcal flies: File-Driver Number 1 


99t999999999999999999999999999999999999 9 99^9 9999^999*999999999999999 


%flle-drlver. inf ©(false, 14, 512, 20) 


Request part: 


req«tabie 

rea-file-driver 

& 

& 

& 

& 

fi 

& 

& 

& 

K 

& 

& 

& 

& 

& 

& 

& 

& 

& 

G 

& 

& 

& 

&> 

req-tabie 


seqment 

< 

rencreatef He, 

9 

reqattachf He, 

9 

reqdetachf He, 


f 


reqoren , 
reqclose, 
reqread, 
reqwrite , 
reqseek, 

9 

reqphyssneciai , 
renconnect Ion status , 
reof Hestatus , 
reogetnatncomponent , 

9 

9 


ends 


; rqSa$create$f He 
t Reserved 
; rq$a$attach$f He 
; Reserved 

? rqSaSdeletesconnection 
? rqsascreatesdirectory 
j Reserved 
; rqSaSdeletesf He 
? Reserved 
; rqSaSrenamesf He 
; rqsaschangesaccess 
; rqSaSooen 
; rqSaSclose 
; rqSaSread 
; rqSaS(*rite 
? rq$a$see)c 
; rqSaStruncate 
; rqsasspeclai 

? rqSaSyetSconnectlonsstatus 
; rqsasgetsf Hesstatus 
? rqSaSgetSpathscomponent 
; rqSaSgetSdlrectorySentry 
; rqSaSgetSextensionSdata 
; rq$a$set$extensionSdata 


Figure 9~4. Physical File Driver Tables 
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; 

; I/O .System part: 


9 

lOS-tdble 

ios«£lle«driver 

Sr 

& 

s. 

Si 

Si 

& 

& 

& 

& 

s; 

s; 

& 

Sr 

& 

s 

s. 

h 

s 

& 

& 

Si 

Sr 

Sr 

& 

&> 

los.tdbie 


segment 

< 

# 

commonlotask , 
phvsupdate r 
attacnpnyslcalf lie , 
attacnPhvslcalf ile. 


phvsread, 
pnvswrl te, 
pnysseetc , 
pnysspeclal , 
attachphysicaldevice , 
commondetachdevice , 
pnvsopen r 

onvsciose, 
comitionae t conns t , 
pnvsoet f iiest , 


pnvsQetpath , 


ohysdetachf ile 
ends 


File-driver Inlt 

I/O (connection) Task 

Update 

Attacn File 

Create File 

Chanae Access (non-nuil path) 
Delete (non-null path) 

Read 

write 

Seek 

Special 

Attact^ Device 

Detacr^ Device 

Open 

Close 

Get Connection status 
Get File status 
Get Extension Data 
Set Extension Data 
Chanae Access (null path) 
Delete (null path) 

Rename 

Get Path Comoonent 
Get Directory Entry 
Truncate 
Detach File 


Figure 9-4. Physical File Driver Tables (continued) 

Figure 9-5 shows the portion of ITABLE.A86 that contains the 
%FILE_DRIVER_INFO call, the request table, and the ios table for the 
stream file driver. 
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SYSTEM 



rqSaScreateSf lie 
Reserved 

rq$a$attach$f ile 
Reserved 

rqSaSdeleteSconnection 

rqSaScreatesdirectory 

Reserved 

rqSaSdeleteSf ile 
Reserved 

rqSdSrenamesf i le 

rqSaSchangesaccess 

rqSaSooen 

rqSaSclose 

rqSaSread 

rqSaSwrlte 

rqSaSseek 

rqSaStruncate 

rqSaSSDecial 

rqSaS get Sconnect Ions status 

rqSaSgetSfilesstatus 

rqSaSgetSpathscomponent 

rqSaSgetSdirectorySentry 

rqSaSgetSextensionSdata 

rqSaSsetSextensionSaata 


Tables 
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I/O System part: 


ios^ptable 
los.f ile.dr iver 
& 

& 

i; 

& 

s; 

& 

& 

& 

& 

s. 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

&> 

ios-tabie 


seqment 

< 

nullfdinlt , 
commonl otasK , 

9 

attacnstreamfile, 

createstreamfile. 


strread, 

strwrite, 

9 

strsoeciai , 
attachstreamdevice, 
cornmondetachdevlce , 
stroDen , 
strclose , 
commonqe t conns t , 
strgetf i lest, 

9 

9 

9 

strdeiete, 

strgetpath, 

9 

9 

strdetachflle 

ends 


File-driver Inlt 

T/n (connection) Task 

Update 

Attacn File 

Create File 

Chance Access (non-null path) 
Delete (non-null path) 

Read 

Write 

Seen 

Specl al 

Attacn Device 

Detach Device 

Open 

Close 

Get Connection status 
Get File status 
Get Fxtenslon Data 
Set Extension Data 
Chanoe Access (null path) 
Delete (null path) 

Rename 

Get Path Component 
Get Directory Entry 
Truncate 
Detach File 


Figure 9-5. Stream File Driver (continued) 


Figure 9-6 shows the portion of ITABLE.A86 that contains null structures 
for the reserved file driver, driver 3. You can use structures like 
those contained in Figure 9-6 to exclude any other file driver from your 
application system. To do this, replace the %FILE_DRIVER_INFO call and 
the REQ_FILE_DRIVER and IOS_FILE_DRIVER structures associated with that 
driver with null structures of the following form: 
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zfile_driverj:nfo( 0, 0, 0, 0) 

REqjTABLE SEQIENT 

REQ_PILE__DRIVER < > 
REQJTABLE ENDS 

lOSJTABLE SEGMENT 

IOSJ?ILE_DRIVER < > 
lOS TABLE ENDS 


Even if you make changes to the structures, you must maintain them in the 
order that they appear in the released Basic I/O System configuration 
file. 








File-Driver Numoer 3: Reserved. 


99$f99§9§f9999§9§9§99999$99»ff$9 ft 


%file_drlver_inf 0 ( 0 , 0,0,0) 
Request part: 


req.tabie seoment 

req_f ile.driver <> 
reo.tabie ends 

7 

7 I/O System part: 

• 

9 

los-table seqment 

ios. file. driver <> 
ios.table ends 

Select 


Figure 9-6. Reserved File Driver Tables 


Figure 9-7 shows the portion of ITABLE.A86 that contains the 
%FILEJDRIVER_INFO call, the request table, and the los table for the 
named file driver. 


9-12 




CONFIGURING THE BASIC I/O SYSTEM 






• f • 

m i m 




Darned Files: File-orlver Number 4. 

t 

t 

%f ile.drlver-infoctrue, 26, 1024, 54) 
t 

7 Request part: 


req. table 
raq.f lle.qrlver 
& 

& 

& 

& 

& 

& 

& 

& 

& 

6 

6 

& 

& 

& 

& 

& 

& 

& 

& 

6 

& 

& 

& 

& 

&> 

feq.tabie 


seoment 

< 

reacreatef 1 le, 

9 

reqattachflie, 

9 

reqdetachf lie, 
reacrea ted 1 rectory, 

9 

reodeietef lie, 

t 

reorenametlie, 

reqchangeaccess , 

reaonen , 

renclose, 

renread, 

reawrlte, 

reaseek, 

reatrunc, 

reqnumspeclal , 

reaconnectlonstatus, 

reqf ilestatus , 

reqgetoathcomponent , 

reage tdirectoryentry , 

rennumqetextenslondata, 

reanumsetextenslondata 

ends 


; rq$a$create$f lie 
7 Reserved 
; rq$a$attach$f lie 
: Reserved 

7 rqSaSdeletesconnection 
7 rqSaScreatesdlrectory 
7 Reserved 
7 rqSaSdeletesf lie 
7 Reserved 
7 rqsasrenamesf lie 
7 rq$aSchange$access 
; rqSaSooen 
; rqSaSclose 
; rqSaSread 
7 rqSaSmrite 
; rqSaSseek 
7 rqSaStruncate 
7 rqSaSspecial 

7 rqSaSgetSconnectionsstatus 
; rq$a$getS£ile$status 
7 rqSaSgetSpathScomponent 
7 rqSaSgetSdlrectorySentry 
; rqSaSgetSextenslonSdata 
7 rqSaSsetSextenslonSaata 


Figure 9-7. Named File Driver Tables 
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I/O System parts 


io«-tdble 
los-f ile-driver 
& 

& 

& 

& 

& 

& 

& 

& 

& 


& 

Se 

& 

& 

& 

s 

los-tahie 


seoroent 

< 

9 

commoniotasK , 
numuDdat ^ , 
attacnnamertfiie, 
createnamedt 11? » 
na'"e<lchangeaccess, 
nanneddaiete , 
numread , 
numwrite , 
numsaetc , 
numsoeclal , 
attacnnameddavica , 
commondetachdevice , 
numoDen , 
numclose , 
commonoetconnst, 
numgetf 1 lest , 
na'T'yataxtdata , 
namsataxtdata , 
nantchaccess , 
namdaiata , 
namraname , 
namgatDdth » 
namdl rentry , 
numtrunc , 
numdatachf lla 

ands 


File-driver Inlt 

T/0 (connection) TasK 

Update 

Attach File 

Create File 

Chanoe Access (non-null oath) 
Delete (non-null path) 

Read 

Write 

SecK 

Special 

Attach Device 

Detach Device 

Open 

Close 

Cet Connection status 
Get File Status 
Get Rxtenslon Data 
Set extension Data 
Change Access (null path) 
Delete (null path) 

Rename 

Get Path Component 
Gat Directory Entry 
Truncate 
Detach File 


Figure 9-7. Named File Driver Tables (continued) 


You can modify the file driver tables in one of two ways. If you want to 
exclude an entire driver from your Basic I/O System, substitute null 
structures for its %FILE_DR1VER_INF0 call and its REQJFILEJORIVER and 
IOS_FILE_DRIVER structures in ITABLE.A86. However, if you want to 
eliminate one or more system calls from a file driver but still include 
the file driver as part of your Basic I/O System, delete the procedure 
names associated with the affected system calls from both the 
REQ_FILE_DRIVER structure and the IOS_FILE_DRIVER structure. 
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Replace the procedure names in the REQ_FILE_DRIVER structure with the 
name NOTCONFIGURED. Replace the procedure names in the IOS_FILE_DRIVER 
structure with commas* This causes the Basic I/O System to return the 
E$NOT$CONFIGURED exception code to any task that attempts to invoke one 
of the eliminated system calls* Table 9-1 lists the system calls and 
associated procedure names for the physical file driver* Table 9-2 lists 
the system calls and associated procedure names for the stream file 
driver* Table 9-3 lists the system calls and the associated procedure 
names for the named file driver* 


Table 9-1* Physical File Driver System Calls and Procedure Names 


SYSTEM CALL 

REQ FILE DRIVER 

lOS FILE DRIVER 


NAME 

NAME 

A$CREATE$FILE 

REQCREATEFILE 

ATTACHPHYSICALFILE 



(the second one) 

A$ATTACH$FILE 

REQATTACHFILE 

ATTACHPHYSICALFILE 



(the first one) 

A$OPEN 

REQOPEN 

PHYSOPEN 

A$SEEK 

REQSEEK 

PHYSSEEK 

A$READ 

REQREAD 

PHYSREAD 

A$WRITE 

REQWRITE 

PHYSWRITE 

A$SPECIAL 

REQPHYSSPECIAL 

PHYSSPECIAL 

A$ CLOSE 

REQCLOSE 

■ 

PHYSCLOSE 

A$GET$CON- 



NECTION$STATUS 

REQCONNECTIONSTATUS 

PHYSGETCONNST 

A$GET$FILE$STATUS 

REQFILESTATUS 

PHYSGETFILEST 

A$GET$PATH$COM- 



PONENT 

REQGETPATHCOMPONENT 

PHYSGETPATH 

A$DELETE$CON- 



NECTION 

REQDETACHFILE 

PHYSDETACHFILE 
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Table 9-2. Stream File Driver System Calls and Procedure Names 


SYSTEM CALL 

REQ FILE DRIVER 
NAME 

lOS FILE DRIVER 
NAME 

A$CREATE$FILE 

REQCREATEFILE 

CREATESTREAMFILE 

A$ATTACH$FILE 

REQATTACHFILE 

ATTACHSTREAMFILE 

A$OPEN 

REQOPEN 

STROPEN 

A$READ 

REQREAD 

STRREAD 

A$WRITE 

REQWRITE 

STRWRITE 

A$ SPECIAL 

REQSTRSPECIAL 

STRSPECIAL 

A$CLOSE 

REQCLOSE 

STRCLOSE 

A$GET$CON- 

NECTION$STATUS 

REQCONNECTIONSTATUS 

STRGETCONNST 

A$GET$FILE$STATUS 

REQFILESTATUS 

STRGETFILEST 

A$GET$PATH$COMPONENT 

REQGETPATHCOMPONENT 

STRGETPATH 

A$DELETE$CONNECTION 

REQDETACHFILE 

STRDETACHFILE 

A$DELETE$FILE 

REQDELETESTRFILE 

STRDELETE 
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Table 9-3. Named File Driver System Calls and Procedure Names 


SYSTEM CALL 

REQ FILE DRIVER 
NAME 

lOS FILE DRIVER 
NAME 

A$CR£ATE$FILE 

REQCREATEFILE 

CREATENAMEDFILE 

A$ATTACH$FILE 

REQATTACHFILE 

ATTACHNAMEDFILE 

A$CREATE$DIRECTORY 

REQCREATEDIRECTORY 

CREATENAMEDFILE 

A$CHANGE$ACCESS 

REQCHANGEACCESS 

NAMEDCHANGEACCESS 

NAMCHACCESS 

A$RENAME$F1LE 

REQRENAMEFILE 

NAMRENAME 

A$OPEN 

REQOPEN 

NDMOPEN 

A$SEEK 

REQSEEK 

NUMSEEK 

A$READ 

REQREAD 

NUMREAD 

A$WRITE 

REQWRITE 

NUMWRITE 

A$SPECIAL 

REQNUMSPECIAL 

NUMSPECIAL 

A$CLOSE 

REQCLOSE 

NUMCLOSE 

A$GET$CON- 

NECTION$STATUS 

REQCONNECTIONSTATUS 

NUMGETCONNST 

A$GET$FILE$STATUS 

REQFILESTATUS 

NUMGETFILEST 

A$GET$DI- 

RECTORY$ENTRY 

- . - - - - - . 1 

REQGETDIRECTORYENTRY 

NAMDIRENTRY 

A$GET$PATH$COMPONENT 

REQGETPATHCOMPONENT 

NAMGETPATH 

A$DELETE$CONNECTION 

REQDETACHFILE 

NUMDETACHFILE 

A$TRUNCATE 

REQTRUNC 

NUMTRUNC 

A$DELETE$FILE 

REQDELETEFILE 

NAMEDDELETE 

NAMDELETE 

A$GET$EXTENS10N$DATA 

II ,.|_ . j 

REQNUMGETEXTENSIONDATA 

NAMGETEXTDATA 

A$ SET$EXTENS ION$DATA 

REQNUMSETEXTENSIONDATA 

NAMSETEXTDATA 
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In addition to the file driver tables shown In Figures 9-4, 9-5, 9-6, and 
9-7, ITABLE.A86 also contains external declarations for all the symbols 
referenced by the REQJPILE_DRIVER and the IOS__FILE__DRIVER structures* If 
you modify these structures to exclude system calls from your Basic I/O 
System, you can eliminate the EXTRN statements for the excluded procedure 
names, as long as these procedure names are not referenced by other file 
driver structures* However, make sure that all references to a procedure 
name have been eliminated before removing Its EXTRN statement* 


Exanqple: 

To remove the A$RENAME$FILE system call from the nan^d file driver, 
replace the REQRENAMEFILE procedure name In the named file driver 
REQ_FILE_DRIVER structure with RQNOTCONFIGURED* Also replace the 
NAMRENAME procedure name in the named file driver IOS_FILE_DRIVER 
structure with a comma* Then remove the EXTRN statements for these names 
from the configuration file* 


SELECTING FEATURES (ITABLE.A86) 


Figure 9-8 shows the part of ITABLE*A86 that selects features of the 
Basic I/O System* These features are selected with macro calls, much In 
the same way as the non-flle/connectlon Interfaces* However, unlike the 
non-file/connectlon Interface, features are selected by excluding the 
corresponding macro call from ITABLE*A86* In order to Include a macro 
call from ITABLE*A86 (and thus exclude the feature), replace the 
semicolon (;) at the beginning of the corresponding macro call with a 
percent-sign (X)* 


• • • • 


9$9§9999§$§t*$9f*99$f$9 


WWW 


; 

i Define any features to be configured. 


999999 99 9 9999 999999999§99999999999999999999999999999999 9 9 9 


;dummy-,cI.Tier 

?no«create«faise 

jfno«truncate 

;no.allocate 


Figure 9-8* Basic I/O System Features 
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The following paragraphs discuss each of the macros shown in Figure 9-8. 

%DDMMY_TIMER The presence of this macro call causes the Basic I/O 
System to be assembled without timing facilities. 

Without timing facilities, the Basic I/O System fills in 
all time fields with a zero value and saves the overhead 
of maintaining a timer. Also, without timing facilities 
you can debug your application system in single-step 
mode using the iSBC 957A/B monitor, because the system 
is not constantly servicing clock interrupts. However, 
if you include the %DUMMY_TIMER macro call, you should 
exclude the GET$TIME and SET$TIME system calls from your 
Basic I/O System. 

If you exclude the %DUMMY_TIMER call from ITABLE.A86, 
the timing facilities of the Basic I/O System are 
included in your application system. 

The presence of this macro call causes the Basic I/O 
System to be assembled without the ability to create 
connections to existing files with the CREATE$FILE 
system call. In particular, if this macro is present, 
the user cannot call CREATE$FILE with the must$create 
parameter set to false. If the Basic I/O System 
encounters such a call, it returns the E$SUPPORT 
exception code. This option Inqplles that CREATE$FILE 
can only be used to create connections to nonexistent 
files. Refer to the iRMX 86 BASIC I/O SYSTEM REFERENCE 
MANUAL for detailed information concerning the 
CREATE$FILE system call. 

%NO_TRUNCATE The presence of this macro call causes the Basic I/O 

System to be assembled without the TRUNCATE system call 
and its associated modules. The presence of this macro 
call also requires the presence of the %NO_CREATE_FALSE 
call, since setting the must$create parameter of 
CREATE$FILE to false requires the ability to truncate 
the file (refer to the iRMX 86 BASIC I/O SYSTEM 
REFERENCE MANUAL). This macro call also requires that 
you omit the TRUNCATE and DELETE$FILE system calls from 
your application system by removing their entries from 
the file driver tables (refer to the "File Driver 
Tables” section of this chapter). 

%N0 _^LOCATE The presence of this macro call causes the Basic I/O 

System to be assembled without the abilirty to extend 
files beyond their current end^f-file boundaries. This 
macro call requires that you omit the CREATE$FILE and 
CREATE$DIRECTORY system calls from your application 
system by removing their entries from the file driver 
tables (refer to the "File Driver Tables" section of 
this chapter). You should not include this macro call 
in ITABLE.A86 unless the users of the Basic I/O System 
only read from existing files on named-file volumes. 
However, Inclusion of this macro call reduces the size 
of the Basic I/O System. 


%NO_CREATE_- 

FALSE 
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DESCRIBING THE I/O DEVICES (IDEVCF,A86) 

An I/O device consists of a controller and one or more units* A device 
driver services each I/O device. In order to Include I/O devices In your 
system, you must provide specific Information about devices, units, and 
device drivers as well as general Information about all devices In the 
system. The specific Information Is provided In the form of device-unit 
Information blocks (DUIBs). The general Information Is provided In the 
form of a macro call. The Basic I/O System configuration file, 
IDEVCF.A86, contains several DUIBs for standard devices as well as the 
general Information for these devices. 

Using the Information presented In this chapter as a guide, you must 
modify IDEVCF.A86 so that it describes the devices attached to your 
system. 

Before presenting the specific Information that you need In order to 
modify the configuration file, this chapter describes the terms device 
number, unit number, and device-unit number, since you must specify each. 


DEVICE NUMBERING 

Figure 9-9 contains a simplified drawing of three I/O devices In a 
system. Tlie device ntmbers of these three devices are 0, 1, and 2, as 
shown. The device number represents the device as a whole. A unit 
number uniquely Identifies a unit within a device (such as a single disk 
drive of a multi-drive device). Notice that the unit numbers of one 
device can duplicate the unit numbers of another. A device-unit number 
uniquely Identifies a unit of a device among all the units of all the 
devices. Device-unit numbers are not duplicated. 


DEVICE 0 


DEVICE 1 


DEVICE 2 



Figure 9-9. Device Numbering 
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Before creating your Basic I/O System configuration file, assign each 
device in your system a device number* Likewise, assign each unit a unit 
number and a device-unit number* The order of assignment is not 
important (with the exception of the unit number), as long as it is 
consistent with the definitions supplied previously, and the numbering of 
devices, units, and device-units begins with 0* The device driver uses 
the unit number to select the correct unit on the device* Make sure that 
if you have two of the same type of controller (such as two iSBC 204 
controllers), assign each of them a separate device number* 


DEVICE-UNIT INFORMATION BLOCKS 

A device-unit information block (DUIB) is a block of information that you 
must supply for each device-unit in your system* You can provide this 
information by entering DEFINE_DUIB assembly language structures into the 
Basic I/O System configuration file* The definition of this structure is 
contained in file IDEVCF*INC, which is available on the Basic I/O System 
release diskette* IDEVCF*A86 contains an $INCLUDE statement for this 
file, which includes it in the assembly of the configuration file* The 
format of the DEFINE_DUIB structure is as follows: 

DEFINEJDUIB < 

& dev_name , 

& f ile_drivers, 

& functions, 

& flags, 

& dev_gran, 

& low_dev_size, 

& high_dev_slze, 

& device_number , 

& uni t_number , 

& devlce_unit_number, 

& lnit_io, 

& finlsh_io, 

& queue_lo, 

& cancel_io, 

& device_info, 

& unit_info, 

& update_tlmeout, 

& num_buffers, 

& priority 

& > , 
where: 

dev_name Name of the device-unit* Specify this name as 

a string of 14 characters or less, surrounded 
by single quotes* This name is supplied to the 
PHYSICAL$ATTACH$DEVICE system call in order to 
identify the device to be attached* For 
exanq>le, the name 'FO' could be used as the 
name of an ISBC 204 unit* 
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file drivers 


functions 


flags 


WORD specifying file driver validity. Setting 
bit number 1 of this word implies that file 
driver number 1+1 can attach this device-unit. 
Clearing bit number 1 implies that file driver 
number 1+1 cannot attach this device-unit. 

Bits are ntimbered from right to left, starting 
with bit 0. Legitimate file drivers and their 
associated bit numbers Include: 


File Driver 
physical 
stream 
named 


Bit Number 
0 
1 
3 


The remainder of the word must be set to zero. 


BYTE specifying I/O function validity. Setting 
bit number 1 of this word implies that this 
device-unit supports function number i. 

Clearing bit number i implies that the 
device-unit does not support function number 
i. Bits are numbered from right to left, 
starting with bit 0. Legitimate functions and 
their numbers Include: 


Function 

F$READ 

F$WRITE 

F$SEEK 

F$SPECIAL 

F$ATTACH$DEV 

F$DETACH$DEV 

F$0PEN 

F$CL0SE 


Bit Number 
0 
1 
2 

3 

4 

5 

6 
7 


Bits 4 and 5 must always be set. Every device 
driver requires these functions. Bits 8-15 of 
this word must be set to zero. 


BYTE specifying characteristics of diskette 
devices. The significance of the bits is as 
follows: 


bit meaning 

0 0 * not a diskette; 1 =* a diskette 

1 0 = single density; 1 = double 

density 

2 0 = single sided; 1 =• double sided 

3 0 » 8 inch; 1 =• 5 1/4 inch 

4-7 Reserved 
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dev_gran 


low dev size 


high_dev_s ize 
device number 


unit number 


device unit number 


init io 


finish io 


WORD specifying the device granularity in 
bytes. This parameter is generally used for 
random access devices (described later in this 
section). It specifies the minimum number of 
bytes of information that the device reads or 
writes in one operation, or the sector size of 
the device. You should set this value equal to 
the volume granularity specified when the 
volume was formatted. For example, for an 
iSBC 204 or ISBC 206 unit you could specify 128 
or 512. 

Low-order WORD of the device storage capacity, 
in bytes. 

High-order WORD of the device storage capacity, 
in bytes. 

BYTE specifying the number of the device with 
which this DUIB is associated. Refer to the 
"Device Numbering" section of this chapter for 
more specific information. 

BYTE specifying the unit number of the device- 
unit associated with this DUIB. This number 
identifies one out of several possible units of 
a device. Refer to the "Device Numbering" sec- 
tion of this chapter for more information. 

WORD specifying the number of the device-unit 
associated with this DUIB. Refer to the 
"Device Numbering" section of this chapter for 
more specific information. 

WORD specifying the offset in the code segment 
of this unit's Initialize I/O device driver 
procedure. Refer to Table 9-4 for special 
information concerning common and random access 
drivers. The GUIDE TO WRITING DEVICE DRIVERS 
FOR THE iRMX 86 AND IRMX 88 I/O SYSTEMS 
contains additional information about this 
procedure. You must also place an EXTRN 
statement for the lnit_lo parameter in the 
configuration file. 

WORD specifying the offset in the code segment 
of this unit 's Finish I/O device driver 
procedure. Refer to Table 9-4 for special 
information concerning common and random access 
drivers. The GUIDE TO WRITING DEVICE DRIVERS 
FOR THE IRMX 86 AND iRMX 88 I/O SYSTEMS 
contains additional information about this 
procedure. You must also place an EXTRN 
statement for the finish_lo parameter in the 
configuration file. 
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queue lo 


cancel io 


device info 


unit info 


update timeout 


WORD specifying the offset in the code segment 
of this unit's Queue I/O procedure* Refer to 
Table 9-4 for special information concerning 
common and random access drivers. The GUIDE TO 
WRITING DEVICE DRIVERS FOR THE IRMX 86 AND 
iRMX 88 I/O SYSTEMS contains additional 
information about this procedure. You must 
also place an EXTBIN statement for the queue _lo 
parameter in the configuration file. 

WORD specifying the offset in the code segment 
of this unit's Cancel I/O procedure. Refer to 
Table 9-4 for special information concerning 
common and random access drivers. The GUIDE TO 
WRITING DEVICE DRIVERS FOR THE IRMX 86 AND 
iRMX 88 I/O SYSTEMS contains additional 
information about this procedure. You must 
also place an EXTRN statement for the cancel_io 
parameter in the configuration file. 

POINTER to a device information table for this 
device. Specify 0 for this parameter if the 
driver for the associated device does not need 
this field. Refer to the "Device and Unit 
Information" section of this chapter for 
specific information concerning the 
device-information table. 

POINTER to a unit information table for this 
unit. Specify 0 for this parameter if the 
driver for the associated unit does not need 
this field. Refer to the "Device and Unit 
Information" section of this chapter for 
specific information concerning the 
unit-information table. 

WORD specifying the number of clock intervals 
(defined during Nucleus configuration; see 
Chapter 6) that the I/O system waits after 
completing an I/O request before updating file 
data structures on the volume. After a request 
on a connection has been completed, the Basic 
I/O System updates the data structures on the 
volume unless a new request is made before this 
timeout value expires. If you specify a zero 
value for this parameter, the Basic I/O System 
updates the structures during each request. A 
value of OFFFFH indicates that updates occur 
only when the device is detached. 

When your Basic I/O System is in the debugging 
stages, you should specify a zero timeout 
value. Otherwise it is recommended that you 
specify a value for this parameter that when 
multiplied by the length of a clock Interval 
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yields an update timeout value of about 1 
second, unless your system can maintain disk 
Integrity with the OFFFFH value. You can 
adjust the update_tlmeout value In conjunction 
with the num_buffers parameter to Increase the 
performance of the Basic I/O System when 
dealing with this unit. 

num_buffers WORD which specifies whether a device Is a 

random access device and, If It Is, specifies 
how many buffers the device uses. If this 
parameter Is nonzero. It specifies that the 
device Is of the random access variety and 
Indicates the number of buffers this unit will 
have for blocking and deblocking I/O requests. 
Each sector Is one buffer plus 16 bytes long. 
The Basic I/O System uses these buffers to 
store partial blocks of data when I/O requests 
do not start on sector boundaries or transfer 
counts are not multiples of the device 
granularity. In most application systems, 4 Is 
an optimal value for this parameter. A value 
of 0 for this parameter Indicates that the 
device Is not a random access device. 

priority BYTE specifying the priority of the Basic I/O 

System service task for the device. 


You must specify a DEFINE_DDIB structure for each device-unit In the 
system. However, you can specify more DUIB structurjes than 
device-units. Each DUIB must have a unique name (specified with the 
dev_name parameter) but more than one DUIB can apply to the same 
device-unit. Different DUIBs can be used to specify different 
characteristics for the same device-unit. Therefore, different device or 
unit characteristics can be selected at run-time when the DUIB Is 
associated with the device-unit (such as choosing between single- and 
double -density diskettes, for example). This is done with the 
A$PHYSICAL$ATTACH$DEVICE system call. You must arrange all of the DUIBs 
contiguously in your configuration file. Do not place any other code 
between the DEFINE_DUIB structures. 

The Basic I/O System supports the notion of common and random access 
drivers, providing a set of support routines for these drivers. When you 
use common and random access drivers you must reference these 
Intel-supplied procedures In the DEFINE_DUIB structure. The DEFINE_DUIB 
parameters and the values which you must enter are listed In Table 9-4. 
The GUIDE TO WRITING DEVICE DRIVERS FOR THE IRMX 86 AND IRMX 88 I/O 
SYSTEMS discusses common and random access device drivers In more detail. 
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Table 9~4. Coamon and Random Access Driver DUIB Values 


DEFINE DUIB 

Coismon and Random Access Driver 

Parameter 

Paraoieter 

init_lo 

INITIO 

finlshjlo 

FINISHIO 

queue^io 

QUEUEIO 

cancel lo 

CANCELIO 




Former releases of the Basic I/O System provided two versions of the 
procedures listed In Table 9-4, one version for common drivers and one 
version for random access drivers* The random access procedures had the 
names listed In Table 9-4, but with the characters "RAD" as a preface* 
Now, the procedures listed In Table 9-4 provide support for both types of 
drivers* However, to be compatible with previous releases, the "Rj^" 
names are still supported* If you are using a configuration file created 
In a previous release, you need not modify It to update these names* 

IDEVCF.A86 contains DEFINE_DUIB structures for several standard devices* 
Figure 9-10 shows one of these structures* 


; Shugart 204, 

f 

def lne»duib 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

& 

6 

& 

& 

&> 


unit 1 



< 

'FI 

9 

Name(14) 

00BH» 

• 

f 

f ileSdrivers 

OFFH, 

• 

9 

f uncts 

OOH, 

f 

flags 

128, 

• 

9 

devsaran 

0fc:900ri,03H, 

« 

9 

devssize s 256 

0, 

• 

9 

Device 

1, 

• 

9 

Unit 

1 f 

• 

9 

devsunlt 

initio, 

• 

9 

InitSio 

finishlo. 

• 

# 

f inisn$io 

queuelo. 

• 

9 

queueslo 

canceilo. 

• 

9 

cancelSio 

dinfo.204. 

: 

devicesinfo 

uinf o.shugart , 

• 

9 

unitSinfo 

100, 

• 

9 

updatestiroeout 

6, 

• 

9 

numsbuf fers 

129 

0 

9 

priority 


Figure 9-10* Example DUIB Contained In IDEVCF*A86 
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The DUIB in Figure 9-10 defines an iSBC 204 unit. The name of this DUIB 
is FI. This name should be used when making an A$PHYSICAL$ATTACH$DEVICE 
system call. The parameters of the DUIB describe the unit as follows: 

• The OBH value for the file_drivers parameter Indicates that file 
drivers one, two, and four can attach this device-unit (bits 0, 

I, and 3 are set). 

• The OFFH value for the functions parameter indicates that all 
eight functions are valid for this device-unit (bits 0-7 are set). 

• The OOH value for the flags parameter indicates that the drive is 
a single-density, single-sided diskette drive. 

• The 0E900H value for the low_dev_slze parameter and the 03H value 
for the high_dev_size parameter indicate a storage capacity of 
3E900H bytes, or 256256 decimal bytes. 

• The values for the device_number, unit_number, and 
device_unit_number parameters indicate that this DUIB applies to 
device-unit 1, which is unit 1 of device 0. 

• The init_lo, finish_io, queue_io, and cancel_lo parameters 
indicate that this ISBC 204 device has a random access driver. 
These parameters contain the values listed in Table 9-4 for 
random access and common driver entry points. IDEVCF.A86 
contains EXTRN statements for these entry points. 

• The device_info and unit_info parameters indicate that this 
device has a device information table located at the address of 
symbol DINFO_204 and this unit has a unit information table 
located at the address of symbol UNIF0_SHUGART . IDEVCF.A86 
contains these tables. They are described in the next section. 


DEVICE AND UNIT INFORMATION TABLES 

The device_lnfo and unit _info parameters of DEFINE_DUIB refer to tables 
that you must place in the configuration file which contain specific 
information that the driver needs. The format of the information in each 
table depends on the device driver. This section describes the formats 
of the device information tables and unit information tables for common 
and random access device drivers. The GUIDE TO WRITING DEVICE DRIVERS 
FOR THE iRMX 86 AND IRMX 88 I/O SYSTEMS contains more complete 
information about these device drivers. 


Common Device Driver Tables 

To provide device information tables for common device drivers, use the 
C(MI0N_DEV_INF0 assembly language structure. This structure is defined 
in file IDEVCF.INC, which is available on the Basic I/O System release 
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diskette* IDEVCF.A86 contains an $INCLUDE stateinent for this file, which 
Includes It In the assembly of the configuration file* The format of the 
COMMON_DEV_INFO structure Is as follows: 

COMMON__DEV_INFO < 

& level, 

& priority, 

& stack_slze, 

& data_slze, 

& num_unlts , 

& devlce_lnlt, 

& devlce_f Inlsh, 

& devlce_start, 

& devlce_stop, 

& devlce_lnterrupt 

& > 


where: 

level WORD specifying an encoded Interrupt level at which 

the device will Interrupt. The Interrupt task uses 
this value to associate Itself with the correct 
Interrupt level. The values for this field are 
encoded as follows: 

bits value 

15-7 0 

6-4 First digit of the Interrupt level (0-7) 

3 If one, the level Is a master level and bits 
6-4 specify the entire level number. If 
zero, the level Is a slave level and bits 2-0 
specify the second digit 

2-0 Second digit of the Interrupt level (0-7), If 
bit 3 Is zero. 


priority BYTE specifying the Initial priority of the device’s 
Interrupt task. 


stack_slze WORD specifying the size In bytes of the stack for the 
user-written device Interrupt procedure (and other 
procedures that It calls). This number should not 
Include stack requirements for the Basic I/O 
System-supplied procedures. They add their 
requirements to this number. 

data_slze WORD specifying the size In bytes of the user portion 

of the device-local data. This data Is for driver use 
only. The common driver support procedures supplied 
by the Basic I/O System allocate their data In 
addition to this. 
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num_unlt8 WORD specifying the number of units supported by the 

driver* Units are assumed to be numbered 
consecutively, starting with zero. 

device_lnit WORD specifying the start address of the user-written 
device Initialization procedure* 

device_flnish WORD, specifying the start address of the user-written 
device finish procedure* 

device_start WORD specifying the start address of the user-written 
device start procedure* 

device_8top WORD specifying the start address of the user-written 
device stop procedure* 

devlce_ln- WORD specifying the start address of the user-written 
terrupt device Interrupt procedure. 

Depending on the actual device driver, you may have to provide additional 
fields for this structure* The GUIDE TO WRITING DEVICE DRIVERS FOR THE 
IRMX 86 AND iRMX 88 I/O SYSTEMS describes all fields of this structure in 
more detail* 

Most common device drivers do not require unit information tables. 
Therefore, make sure to set the unit_info field of the DEFINE_DUIB 
structure to zero for any device-units that use common device drivers, 
unless the particular driver requires unit information. 


Random Access Device Driver Tables 

To provide the device Information tables and unit information tables for 
random access device drivers, use the RADEV_DEV_INFO and RADEV_UNIT_INFO 
assembly language structure* These structures are defined in file 
IDEVCF.INC, which is available on the Basic I/O System release diskette* 
IDEVCF.A86 contains an $INCLUDE statement for this file, which Includes 
it in the assembly of the configuration file* 

The format of the RADEV_DEV_INFO structure is as follows: 

RADEV_DEV_INFO < 

& level, 

& priority, 

& stack_size, 

& data_slze, 

& num_units, 

& device_init, 

& device_f inish, 

& device_start, 

& device_stop, 

& device_interrupt 

& > 
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The fields of this structure are the same as those for the 

COMMON DEV_INFO structure and are described In the "Common Device Driver 

Tables’*” section of this chapter. 

Depending on the actual device driver, you may have to provide additional 
parameters for this structure. Refer to the "Device Driver Tables for 
Intel-supplied Device Drivers" section of this chapter for examples of 
this. The GUIDE TO WRITING DEVICE DRIVERS FOR THE iRMX 86 AND iRMX 88 
I/O SYSTEMS describes all of the fields of this structure in detail. 


To provide the unit information table for a random access device driver, 
use the RADEV_UNIT_INFO assembly language structure. The format of this 
structure is as follows: 

RADEV_UNIT__INFO < 

& track_size, 

& max_retry, 

& 0 

& > 

where: 

track_slze WORD specifying the size in bytes of one track of a 
volume of the device. If the controller can handle 
requests that cross track boundaries, specify 0 for this 
parameter. 

max_retry WORD specifying the maximum number of times an operation 
should be retried if an error occurs. A value of 9 is 
recommended. 

Depending on the actual device driver, you may have to provide additional 
parameters for this structure. Refer to the "Device Driver Tables for 
Intel-supplied Device Drivers" section of this chapter for examples of 
this. Also refer to the GUIDE TO WRITING DEVICE DRIVERS FOR THE IRMX 86 
AND IRMX 88 I/O SYSTEMS for further information about this structure. 


DEVICE-DRIVER TABLES FOR INTEL-SUPPLIED DEVICE DRIVERS 
Intel supplies device drivers for the following devices: 

ISBC 204 flexible disk controller 
iSBC 206 hard disk controller 
ISBC 208 flexible disk controller 

iSBC 215/lSBX 218/ iSBC 220 winches ter /flexible/SMD disk controller 
ISBC 254 bubble memory controller 


9-30 



CONFIGURING THE BASIC I/O SYSTEM 


line printer 

ISBC 86/12A on board USART 
iSBX 270 terminal controller 
byte bucket 


All you have to do In order to use these drivers Is to fill out the 
DUIBs, device Information tables, and unit Information tables as 
described In this section. 

Note that If several boards are configured In the system, each must have 
Its own unique Interrupt level and port addresses. 

In general, flexible disk drivers may support sector sizes of 128, 256, 
512, and 1024 bytes, single or double density (128-byte sector size Is 
not supported with double density), single or double sided. Cylinder 0, 
side 0 Is always formatted with 128-byte sectors, single density. On two 
sided, 8-lnch, double density disks, cylinder 0, side 1 Is always 
formatted with 256-byte sectors, double density. Sectors are mapped Into 
device granularity blocks and assigned a sector number. Sector numbering 
starts with the number 1 on side 0, cylinder 0 and continues 
consecutively around that track. Numbering continues onto side 1, 
cylinder 0 before proceeding to side 0, cylinder 1. 

Characteristics of the supported 8-lnch and 5 1/4-lnch flexible formats 
are shown In Tables 9-5 and 9-6. These characteristics are common to 
both the ISBC 208 and ISBX 218 drivers. Values In these tables do not 
apply to the ISBC 204 driver. 


Table 9-5. Eight Inch Diskette Characteristics 


Sector 

Size 

Density 

Sectors 
per Track 

Device Size 
One Sided 

Device Size 
Two Sided 

128 

Single 

26 

256256 * 

512512 * 

256 

Single 

15 

295168 

590848 

512 

Single 

8 

314880 

630272 

1024 

Single 

4 

315392 

630784 

256 

Double 

26 

509184 * 

1021696 * 

512 

Double 

15 

587264 

1177600 

1024 

Double 

8 

626688 

1255424 

* This device type Is supported by the ISBC 208 and ISBX 218 bootstrap 
drivers. 
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Table 9-6, 51/4 Inch Diskette Characteristics 


Sector 

Size 

Density 

Sectors 
per Track 

Device Size 

One Sided 

35 Tracks 80 Tracks 

Two Sided 

35 Tracks 80 Tracks 

128 

Single 

16 

71680 

163840 

143360 

327680 

256 

Single 

9 

80384 

184064 * 

161024 * 

368384 * 

512 

Single 

4 

71680 

163840 

143360 

327680 

1024 

Single 

2 

71680 

163840 

143360 

327680 

256 

Double 

16 

141312 * 

325632 * 

284672 * 

653312 * 

512 

! Double 

8 

141312 

325632 

284672 

653312 

1024 

1 Double 

4 

141312 

324532 

284672 

653312 


* This device type is supported by the iSBC 208 and iSBX 218 bootstrap 
drivers. 


ISBC 204 Driver 


The iSBC 204 driver is a random access driver. It supports the following: 

o The functions F$READ, F$WRITE, F$SEEK, F$SPECIAL, F$ATTACH$DEVICE, 
and F$DETACH$DEV. F$0PEN and F$CL0SE are accepted, but the driver 
performs no operations for these functions. Track formatting and 
volume change notification are supported via the F$SPECIAL 
function. Refer to the IRMX 86 BASIC I/O SYSTEM REFERENCE MANUAL 
for further information about these special functions. 

o All Intel-supplied file drivers. 

o Device granularities of 128 and 512 bytes, software selectable on a 
per-unit basis. 

o Up to four units per controller; two for each 8271 DMA chip. The 
8271 chip at chip location A4 of the iSBC 204 board is FDCO, 
controlling units 0 and 1. The 8271 chip at chip location A6 is 
FDCl, controlling units 2 and 3. 

You must place the following values in the device Information table in 
order to support the ISBC 204 driver: 


RADEV_DEVJLNF0 Field 

level 

priority 

stack_slze 

data_slze 

num_units 

device inlt 


Value 


Configuration option 
Configuration option 
20 
127 

1 through 4 
I204INIT 
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RADEV DEV INFO Field Value 

DEFAULTFINISH 
I204START 
DEFAULTSTOP 
1204 INTERRUPT 

In addition, you oust also append the following information to the device 
information structure: 

Type Value 

WORD Address of the I/O port which matches the 

board configuration* 

Figure 9-11 shows a device information table contained in IDEVCF*A86. 

This table is the one associated with the DUIB shown in Figure 9-10. 


devlce__flnlsh 
device_start 
devlce_stop 
de vi ce_l nterrup t 


t General 204 Single-Density floppy device information 


dinfo»204 radev«dev«lnf o < 

& 058H, 

& 61 , 

6 20 , 

& 127, 

A 4 , 

6 i204init, 

A defauitf Inlsh, 

A 1204start, 

A defauitstop, 

A 1204lnterrupt 

A> 

dw oaoh 


t level 
; priority 
t staclc$size 
: dataSslze 
; numsunits 
? deviceSinit 
f devicesf Inlsh 
I deviceSstart 
; deviceSstop 
t deviceSinterrupt 

; I/O port base (204 speclfilc) 


Figure 9-11. Device Information Table for ISBC" 204 Device 


IDEVCF.A86 also contains EXTRN statements for the symbols referenced in 
the Figure 9-11. 

You must supply the following information in the unit Information table 
in order to support the ISBC 204 driver: 

RADEV_UNIT__INFO Field Value 

track_slze 26 * 128 or 8 * 512 

max retry 9 (recommended) 
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In addition, you oust append the following information, in sequence, to 
the unit Information structure: 

Type Value 

WORD reserved 

HOIU) reserved 

BYTE step-rate for drive 

BYTE settle time for drive 

BYTE head load/unload time 

Refer to the description of the specify command in the ISBC 204 FLEXIBLE 
DISKETTE CONTROLLER HARDWARE REFEREITCE MANUAL for more information about 
these values* Figure 9-12 shows a unit Information table contained in 
IDEVCF.A86. This table is associated with the DUIB shown in Figure 9-10. 


uinto.shuyart 

& 

& 

& 

&> 

? 204 Specific: 


unit 

Infomatlon: 



radev 

.unit. info < 



26 ♦ 

128, 

t 

track size 

9, 


• 

r 

max retry 

0 


; 

reserved 

dw 

4 

? 

Reserved 

dt> 

035H,0DH 

t 

Fixed initialize values 

db 

8 

t 

step rate 

do 

8 

• 

F 

settle 

db 

039H 

; 

cntsioad 


Figure 9-12. Unit Information Table for iSBC* 204 Unit 


ISBC 206 Driver 

The ISBC 206 driver is a random access driver. It supports the following: 

• The functions F$READ, F$WRITE, F$SEEK, F$SPECIAL, F$ATTACH$DEV, 
and F$DETACH$DEV. F$0PEN and F$CL0SE are accepted, but the 
driver performs no operations for these functions. Track 
formatting and volume change notification are supported via the 
F$SPECIAL function. Refer to the IRMX 86 BASIC I/O SYSTEM 
REFERENCE MANUAL for further information about these special 
functions. 
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• All Intel-supplied file drivers. 

• Device granularities of 128 and 512 bytes, hardware (switch) 
selectable on a per-spindle basis. 

• Up to 16 units per controller. 

The iSBC 206 driver can support four spindles, with up to four platters 
per spindle. Units 0~3 are on the first spindle, 4-7 are on the second, 
8-11 are on the third, and 12-15 are on the fourth. Units 0, 4, 8, and 
12 are the removable platters. 

You must specify the following values in the device information table, in 
order to support the iSBC 206 driver; 


RADEV DEV INFO Field 


level 

priority 


Value 


Configuration option 
Configuration option 


RADEV DEV INFO Field Value 


stack_slze 

data_slze 

num_units 

device_init 

device_finish 

device_start 

device_stop 

device_interrupt 


40 

16 

1 through 16 

I206INIT 

DEFAULTFINISH 

I206START 

DEFAULTSTOP 

I206INTERRUPT 


In addition, you must also append the following data to the device 
information structure; 

Value 


Address of the I/O port which matches the 
board configuration. 


WORD 


You must specify the following values in the unit information table, in 
order to support the iSBC 206 driver; 

RADEV UNIT INFO Field Value 


track_size 
max retry 


36 * 128 or 12 * 512 
9 (recommended) 
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ISBC 208 Driver 

The iSBC 208 dlrver Is a random access device driver. It supports the 
following: 

• The functions F$ATTACH$DEV, F$DETACH$DEV, F$0PEN, F$CLOSE, 

F$READ, F$WRITE, F$SEEK, and F$SPECIAL. F$0PEN is accepted, but 
the driver performs no operations for this function. Track 
formatting is supported by F$SPECIAL. Refer to the iRMX 86 BASIC 
I/O SYSTEM REFERENCE MANUAL for further Information about these 
special) functions. 

• Device granularities of 128, 256, 512, and 1024 bytes. 

• All Intel-supported file drivers. 

• Up to 4 units per controller. 

The ISBC 208 can be attached to the Named or Physical file drivers. It 
is configurable to allow various disk drivers, recording formats, and 
multiple controller boards. Each diskette (1 or 2 sides) is treated as a 
single device-unit. Units 0-3 correspond to the four drives. 

You must specify the following values in the device Information table, in 
order to support the ISBC 208 driver; 

Value 

Configuration option 
Configuration option 
220 
150 

1 through 4 
I208$INIT 
DEFAULTFINISH 
I208$START 
DEFAULTSTOP 
I208$INTERRUPT 

In addition, you must alwo append the following data to the device 
information structure: 

Type Value 

WORD The base address value is the same as the 

shorting plug configuration on the ISBC 208 
board. 

WORD The motor$delay value is the number of system 

clock ticks to wait after turning on a 
minifloppy motor before accessing the drive. 
Motor$delay is only needed for 5 1/4-inch 
diskettes, and is usually set for 1/2-1 second. 


RADEV_DEV_INF0 Field 

level 

priority 

stack _size 

data_size 

num_units 

device_inlt 

device_finish 

devlce_start 

device _stop 

device interrupt 
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You must specify the following values in the unit information table, in 
order to support the iSBC 208 driver: 

RADEV_UNIT_INFO Field Value 

track_size 0 

max_retry 9 (recommended) 

^ In addition, you must append the following information to the unit 
information structure: 

Type Value 

WORD The number of tracks on one side of a disk. 

Typical values are 77 for eight inch diskettes. 

WORD The number of sectors per track. To determine 

the number of sectors per track refer to Table 
9-5 and Table 9-6. 

BYTE The maximum drive step rate, in milliseconds per 

step. 

BYTE The amount of time to wait after an access before 

unloading the head, in milliseconds. 

BYTE The head load time and settling time, in 

milliseconds. 


iSBC 215/iSBX 218/iSBC 220 Driver 

The iSBC 215/iSBX 218/iSBC 220 driver is a random access driver. It 
supports the following: 

• The functions F$READ, F$WRITE, F$SEEK, F$SPECIAL, F$ATTACH$DEV, 
and F$DETACH$DEV. F$0PEN and F$CL0SE are accepted, but the driver 
performs no operations for these functions. Track formatting and 
voliime change notification are supported via the F$SPECIAL 
function. Refer to the iRMX 86 BASIC I/O SYSTEM REFERENCE MANUAL 
for further information about these special functions. 

• All Intel-supplied file drivers. 

• Device granularities of 128, 256, 512, and 1024 bytes. 

• Up to 12 disks per controller. 

The iSBC 215/ISBX 218/iSBC 220 driver assumes that units 0-3 are fixed 
disks on drives 1“4, units 4-7 are removable disks on drives 1-4, and 8-11 
are flexible diskette drives 1-4 (when the iSBX 218 board is used in 
conjunction with the ISBC 215 board). The driver checks only the four 
least -significant bits of the unit number. The upper bits can be used to 
identify multiple units on the same disk, as described in this section. 
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You must specify the following values in the device information table, in 
order to support the ISBC 215/iSBX 218/ iSBC 220 driver. 

RADEV_pEV__INFO Field 

Value 

level 

Configuration option 

priority 

Configuration option 

stack_size 

300 

data_slze 

400 

num_unlts 

12 or more 

devlce_init 

I215INIT 

device_f Inish 

DEFAULTFINISH 

device_start 

I215START 

device_stop 

DEFAULTSTOP 

device_lnterrupt 

I215INTERRUPT 

In addition, you must also 
information structure: 

append the following data the the device 

IZE£ 

Value 

WORD 

Wakeup address offset (normally set to 0) 

WORD 

Wakeup address base 

WORD 

Wakeup port address 

You should set the wakeup address base and the wakeup port address to the 
values set with the switches on the iSBC 215 or ISBC 220 controller board 

You must specify the following values in the unit Information table, in 
order to support the iSBC 215/iSBX 218 driver: 

RADEVJJNITJENFO Field 

Value 

track_size 

0 

max_retry 

9 (recommended) 


In addition, you must append the following information, in sequence, to 
the unit information structure: 




Value 


WORD The device code (0 for the iSBC 215 device and 

2 for the iSBC 220 device) 

WORD The number of cylinders on the iSBC 215 disk* 

BYTE The number of fixed data heads on the disk 

drive. 

BYTE The number of removable data heads on the disk 

drive. For a iSBX 218 flexible disk drive, 
you should set this to 1 or 2 to indicate 
single or double sided diskettes. This 
value should correspond to the flags field 
of the DUIB for the unit. 

BYTE The number of sectors per track. Refer to 

Table 9-5 and Table 9-6 to determine the 
number of sectors per track. 
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Type Value 

BYTE The number of cylinders set aside for alternate 

tracks • 

DWOm) The starting sector number of the device 

(normally 0). By using this field and the 
device size field in the DUIB, you can define 
several units on different parts of a single 
disk drive* 


iSBC 254 Controller 


The ISBC 254 driver is a random access driver. It supports the following: 


• The functions F$READ, F$WRITE, F$SEEK, and F$ATTACH$DEVICE. 
F$DETACH$DEVICE, F$0PEN, and F$CL0SE are accepted, but the driver 
performs no operations for these functions. 

• All Intel-supplied file drivers. 

• Device granularities of 64, 128, 256, and 512 bytes, software 
selectable on a per-unit basis. 

• Three types of hardware configuration: 

Each iSBC 254 board as a complete device with one unit. 

Several iSBC 254 boards as separate units of a single 
imaginary device . 

Several ISBC 254 boards as a single unit. 


You must place the following values in the device information table in 
order to support the ISBC 254 driver: 


RADEV DEV INFO Field Value 


level 

priority 

stack_size 

data_slze 

num_units 

device_lnit 

device_f inish 

device_start 

device_s top 

device interrupt 


Configuration option 
Configuration option 
512 
15 

Configuration option 

DEFAULTINIT 

DEFAULTFINISH 

I254START 

DEFAULTSTOP 

I254INTERRUPT 
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You must specify the following values In the unit Information table. In 
order to support the ISBC 254 driver: 

RADEyjINIT_INFO Field Value 

track _slze 0 

max_retry 9 (recommended) 

In addition, you must append the following Information, In sequence, to 
the unit Information structure: 




Value 


WORD Number of boards In the unit* The boards must 

have contiguous base addresses (20H apart) 
and all boards must be connected to the same 
Interrupt line* The number of pages on all 
but the last board must be the same* 

WORD Base address of the board* 

WORD Number of device-granularity units of memory 

(64-, 128-, 256-, or 512-byte units) on the 
ISBC 254 board* 


Line Printer Driver 

The line printer driver Is a common device driver* It supports the 
following: 


• The functions F$ATTACH$DEV, F$DETACH$DEV, F$OPEN$, F$CLOSE, and 
F$WRITE* F$DETACH$DEV, F$OPEN, and F$CLOSE are accepted, but the 
driver performs no operations for these functions* Refer to the 
IRMX 86 BASIC I/O SYSTEM REFERENCE MANUAL for further Information 
about any of these special functions* 

The line printer driver Interfaces the Basic I/O subsystem file driver to 
the 8255 parallel I/O port of the ISBC 86/12A board* A flat ribbon cable 
connects this board with a Centronix type line printer* The line printer 
Is not a random-access device and can only be attached to the physical 
file driver* 

You must specify the following values In the device Information table. In 
order to support the line plnter driver: 


COMMON DEV_INFO Field 

level 

priority 

stack_slze 

data_slze 

num_unlts 

device _inlt 

devlce_f Inlsh 

devlce_start 

devlce__stop 

device Interrupt 


Value 

Configuration option 
Conflg^ratlon option 
lEH 
0 
1 

DEFAULTINIT 

DEFAULTFINISH 

PRINTERSTARTINTERRUPT 

PRINTERSTOP 

PRINTERSTARTINTERRUPT 
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In addition, you must also append the following data to the device 
information structure: 

Type Value 

WORD The 8255 A-port address. 

WORD The 8255 B-port address. 

WORD The 8255 C-port address. 

WORD The 8255 Control-port address. 

WORD This is a BOOLEAN value indicating whether the line 

printer can handle tabs or not. If TRUE is 
specified, the driver won't interpret tabs. 
Otherwise, all sequential tabs are forced to a 
single blank character. 


ISBC 86/12A On Board USART 


The On Board USART is a Basic I/O System driver interface to the Terminal 
Handler and the Debugger. It supports the functions F$READ, F$WRITE, 
F$ATTACH$DEV, and F$DETACH$DEV. This driver Interfaces to the Basic I/O 
System at the DUIB level. It should only be used by the physical file 
driver. You must specify the following procedure names in the 
DEFINE_DUIB structure in order to support the On Board USART; 


DEFINE_DUIB Field 

lnit_io 
f lnish_io 
queue_io 
cancel lo 


Procedure Name 

THINITIO 

THFINISHIO 

THQUEUEIO 

THCANCELIO 


The device and unit information pointers are ignored. Set the parameters 
device_info and unit_info to 0. 

The USART driver requires a Terminal Handler (or the Debugger's Terminal 
Handler) to be present in the application system. This Terminal Handler 
must use input and output mailbox names RQTHNORMIN and RQTHNORMOUT, 
respectively. 


IRMX 86 Terminal Driver 

The iRMX 86 terminal driver is a Custom Device Driver which allows I/O to 
a terminal device via the onboard serial port of an iSBC 86/1 2A or any 
other iAPX 86,88-based board. This terminal driver Interfaces to the 
Basic I/O subsystem at the DUIB level and eliminates the need to 
interface with the Terminal Handler. It supports the functions F$READ, 
F$WRITE, F$SPECIAL, F$ATTACH$DEV, F$DETACH$DEV, F$0PEN and F$CL0SE. It 
should only be used by the physclal file driver. 
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You must specify the following values in the DEFINEJDUIB structure in 
order to support the iRMX 86 terminal driver: 


DEFINE_DUIB Field 

Value 

flags 

0 

dev_gran 

0 

low _dev_size 

0 

high_dev_8 ize 

0 

device 

Configuration option 

unit 

0 

dev_unit 

Configuration option 

init io 

TERMINITIO 

finishJLo 

TERMFINISHIO 

queue_io 

TERMQUEUEIO 

cancel_io 

TERMCANCELIO 

update_t Imeout 

OFFFFH 

num_buffers 

0 

priority 

Configuration option 


The device and unit information pointers point to the device and unit 
information tables respectively* 

You must specify the following values 

in the device information table in 

order to support the iRMX 

86 terminal 

driver: 

DEFINE_DEVICE Field 

Type 

Value 

num_unlts 

WORD 

1 

data_slze 

WORD 

1024 

. stack_size 

WORD 

700 

device_inlt 

WORD 

USARTINIT 

device_f Inlsh 

WORD 

USARTFINISH 

device_setup 

WORD 

USARTSETUP 

device_input 

WORD 

USARTINPUT 

device_output 

WORD 

USARTOUTPUT 

reserved 

DWORD 

0 

num_int er rup t_leve 1 

WORD 

2 

input_lnterrupt_level 

WOBID 

Interrupt level for the input 
Interrupt* The Interrupt task 
uses this value to associate 
itself with the correct interrupt 
level* The values for this field 
are listed in this chapter's 
section titled "Common Device 
Driver Tables"* 

input_j>riority 

BYTE 

Initial priority of input 


interrupt task* 
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DEFINE_DEVICE Field Type 

output_lnterrupt_level WORD 


output_priority 

BYTE 

usart_data_port 

WORD 

usart_status_j)ort 

WORD 

In^ratejport 

WORD 

in^rate cmd port 

WORD 

ln_rate_counter 

WORD 

in_rate_max 

DWORD 


out_rate_port 

WORD 

out_rate cmd_port 

WORD 

out_rate_counter 

BYTE 

out rate max 

DWORD 


Value 

Interrupt level for the output 

interrupt. The interrupt task uses 
this value to associate Itself with 
the correct interrupt level. The 
values for this field are listed in 
this chapter's section titled 
"Common Device Driver Tables". 

Intitlal priority of the output 
interrupt task. 

8251A data port address. 

8251A control/status port address. 

8253 counter register port 
address for input rate. 

8253 mode control port address 
for input rate 

8263 counter number, 0-2 for 
input rate 

Maximum input baud rate when 
counter register value is 1 
(for 1.23 MHz counter input, this 
field is 76800). 

8253 counter register port 
address for output rate. 

8253 mode control port address 
for output rate. 

8253 counter number, 0-2 for 
output rate. 

Maximum output baud rate when 
counter register value is 1. 


You must specify the following values in the unit information table in 
order to support the iRMX 86 terminal driver: 

DEFINEJJNIT Field Type Value 

conn_flag WORD Connection mode information. The 

significance of the bits is as 
follows: 


Bits Meaning 

0-1 Initial default line editing mode, 

use the values of 1-3. 

Mode 1 is not line-edited (console 
input is transparent). 

Mode 2 is the normal mode used for 
line editing. 

Mode 3 is not line-edited, and 
immediately returns any characters 
in the input buffer. 
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DEFINEJJNIT Field Type Value 

Bits Meaning 

2 Echo; 

0 « a character entered at the 
keyboard is transmitted to the 
communications Interface (USART) 
and Is returned to the terminal 
screen; 

1 * no echo returned. 

3 Input parity control; 

0 = terminal driver sets parity 
bit (bit 7) to 0 on Input 
characters; 

1 * terminal driver does not 
change bit 7 on input characters. 

4 Output parity control; 

0 = terminal driver sets parity 
bit (bit 7) to 0 on output 
characters; 

1 = terminal driver does not 
change bit 7 on output characters. 

5-8 reserved; set value to 0 

term_flags WORD Terminal mode information. The significance 

of the bits is as follows: 


Bits 

Meaning 



0 

Reserved; 

set 

value to 1 

1-3 

Reserved; 

set 

value to 0 

4,5 

Input parity checking; 


0 = ignore parity checking and 
set input parity bit (bit 7) to 0; 

1 * Ignore parity checking and do 
not change input bit; 

2 ■ set input parity bit to zero 
if even parity received, set 
input parity to one if odd parity 
received, if generated output 
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DEFINE UNIT 


in rate 


out rate 


Field Type Value 

Bits Meaning 

4,5 parity is even (2), then set 

input parity bit to 1 if received 

stop bit has a value of 0 
(framing error) or new character 
has been input before interrupt 
routine for character processing 
has completed (overrun error); 

3 = set input parity bit to one 
if even parity received, set 
parity bit to zero if odd parity 
received, if generated output 
parity is odd (3), then set 
input parity bit to 1 if stop 
bit has a value of 0 (framing 
error) or new character has been 
input before interrupt routine 
for character processing has 
completed (overrun error). 

6-8 Generated output parity, use 

values of 0 to 4; if value 2 or 
3 is used and input parity is 
checked, then values 2 or 3 
respectively must be used for 
input parity checking. 

0 = output parity bit is 0; 

1 = set output parity bit to 1; 

2 = set output parity bit to 1 
if the total number of I's in 
the character is odd, set parity 
bit to 0 if the total number of 
I's is even (even parity); 

3 ” set output parity bit to 0 
if the total number of I's in 
the character is odd, set output 
parity bit to 1 if total number 
of I's is even (odd parity); 

4 = don't change output parity 
bit. 

WORD Input baud rate, or zero if not applicable. 

Input value is used for output if device 
has only one baud rate. 


WORD 0 


9-45 


CONFIGURING THE BASIC I/O SYSTEM 


DEFINEJUNIT Field 

Type 


Value 

reserved 

WORD 

0 


reserved 

WORD 

0 



ISBX 270 Terminal Driver 

The iSBX 270 terminal driver is a Custom Device Driver which allows I/O 
to a terminal device consisting of an iSBX 270 terminal controller board 
with a monitor and/or keyboard* This terminal driver Interfaces to the 
Basic I/O subsystem at the DUIB level in the same manner as the IRMX 86 
Terminal Driver. It supports the functions F$READ, F$WRITE, F$SPECIAL, 
F$ATTACH$DEV, F$DETACH$DEV, F$0PEN and F$CL0SE. It should only be used 
by the physical file driver. You must specify the following values in 
the DEFINE_DUIB structure in order to support the iSBX 270 terminal 
driver: 

DEFINE DUIB Field Value 


flags 

0 

dev_gran 

0 

low_de v_s iz e 

0 

high_dev_s Ize 

0 

device 

Configuration option 

unit 

0 

dev_unlt 

Configuration option 

init_lo 

TERMINITIO 

finish_io 

TERMFINISHIO 

queue_io 

TERMQUEUEIO 

cancel_io 

TERMCANCELIO 

update_tiraeout 

OFFFFH 

num_buffers 

0 

priority 

Configuration option 


The device and unit information pointers point to the device and unit 
information tables respectively. 

You must specify the following values in the device information table in 
order to support the iSBX 270 terminal driver: 

DEFINE_DEVICE Field Type Value 


num_units 

WORD 

1 

data_slze 

WORD 

1024 

stackjslze 

WORD 

700 

device_init 

WORD 

I270INIT 

device_f inlsh 

WORD 

I270FINISH 

device_setup 

WORD 

I270SETUP 

device__lnput 

WORD 

I270INPUT 

device_output 

WORD 

I270OUTPUT 

reserved 

DWORD 

0 

num_lnterrupt__level 

WORD 

2 
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DEFINE_DEVICE Field Type 

lnput_lnterrupt_level WORD 


input_priority BYTE 

output_interrupt level WORD 


output_priorlty 

BYTE 

127 0_data_por t 

WORD 

i 27 0_s tatus_por t 

WORD 


Value 

Interrupt level for the output 
buffer full interrupt. The 
interrupt task uses this value to 
associate itself with the correct 
interrupt level. The values for 
this field are listed in this 
chapter's section titled "Common 
Device Driver Tables". 

Initial priority of the output 
full buffer interrupt task. 

Interrupt level for the input 
buffer empty interrupt. The 
interrupt task uses this value to 
associate Itself with the correct 
Interrupt level. The values for 
this field are listed in this 
chapter's section titled "Common 
Device Driver Tables". 

Intltlal priority of the input 
buffer empty interrupt task. 

ISBX 270 data port address. 

ISBX 270 control/status port address. 


You must specify the following values in the unit information table in 
order to support the ISBX 270 teirmlnal driver: 

DEFINEJJNIT Field Type Value 

conn_flag WORD Connection mode information. The 

significance of the bits is as 
follows: 


Bits Meaning 

0-1 Initial default line editing mode, 

use the values of 1-3. 

Mode 1 is not line-^dited (console 
input is transparent). 

Mode 2 is the normal mode used for 
line editing. 

Mode 3 is not line-edited, and 
immediately returns any characters 
in the input buffer. 

2 Echo; 0 = a character entered at 

the keyboard is transmitted to the 
terminal screen; 


1 = no echo returned 
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DEFINE UNIT Field Type 


term_flags WORD 


ln_rate 

WORD 

outjrate 

WORD 

reserved 

WORD 

reserved 

BYTE 


Value 

Bit Meaning 

4 Input parity control; 

0 = set parity bit (bit 7) to 0; 

1 = do not change parity bit (bit 

7 ) 

5- 8 reserved; set to value 0 

Terminal mode information* The significance 
of the bits is as follows: 

Bit Meaning 

0 Reserved; set to value 1 

1-3 Reserved; set to value 0 

4,5 Parity bit from keyboard; 

0 =• set parity bit (bit 7) to 0; 

1 =• do not change parity bit 

6- 8 Reserved; set value to 0 

0 

0 

0 

0 


Byte Bucket Driver 

The Basic I/O System supports a byte bucket device by providing a byte 
bucket driver. This driver responds to F$READ, F$WRITE, F$0PEN, F$CL0SE, 
F$ATTACH$ DEVICE, and F$DETACH$DEVICE, but performs no operations for these 
functions* It returns an exception code on an F$SEEK request* The 
physical file driver and the stream file driver can make use of the byte 
bucket device driver. 

The byte bucket device driver Interfaces to the Basic I/O System at the 
DUIB level* In order to provide support for the byte bucket driver, you 
must specify the following values in the DEFINE__DUIB structure; 

DEFINE DUIB Field Procedure Name 


Init io 


BYTEBUCKETINITIO 


f inish_io 
queue _lo 
cancel io 


BYTEBUCKETFINISHIO 

BYTEBUCKETQUEUEIO 

BYTEBUCKETCANCELIO 
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GENERAL DEVICE INFORMATION 


The Basic I/O System requires that several parameters and RAM-based data 
structures be generated for device configuration* In order for this to 
happen, you must Include a %DEVICE_TABLES macro call in the configuration 
file* Place this call outside of all segment definitions in your Basic 
I/O System configuration module and immediately following the DEFINE_DUIB 
structures* The released configuration file contains an example macro 
call in the proper place* Modify this call to reflect your system. 

The file IDEVCF.INC contains the definition of %DEVICE_TABLES macro* 
IDEVCF.A86 contains an $INCLUDE statement for this file, which Includes 
it in the assembly of the configuration file* 

The format of the macro call is as follows: 


%DEVICE_TABLES(num_dulb, num_de v_unit , num_devices) 
where: 


num duib 


Number of DUIBs that you have defined with the 
DEFINE DUIB structure* 


num dev unit 


num devices 


Number of device-units that you have defined* 
This number is 1 + (the largest dev_unit_number 
parameter)* The dev_unit_number parameter was 
entered with the DEFINE_DUIB structure* 

Number of devices defined* This number is 1 + 
(the largest device_number parameter)* The 
device_number parameter was entered with the 
DEFINE DUIB structure* 


ASSEMBLING THE CONFIGURATION FILES, LINKING AND LOCATING THE BASIC I/O 
SYSTEM 

After you have modified ITABLE.A86 and IDEVCF.A86 to conform to your 
system requirements, you must assemble them and link and locate the Basic 
I/O System* lOS.CSD, a SUBMIT file contained on the Basic I/O System 
release diskette, can be used to perform these functions* In order to 
use this SUBMIT file, you must first prepare your diskettes and place 
them in the proper drives of your development system, as explained in the 
"Linking and Locating the Subsystems" section of Chapter 4* You should 
also examine ITABLE.A86 and IDEVCF.A86 to make sure that the $INCLUDE 
statements contain the proper disk identifiers* Then you can enter the 
following command: 

SUBMIT :fx:IOS(date, loc_adr) 
where: 

fx The appropriate disk identifier, indicating the 

drive containing lOS.CSD* 
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date The date on which you submit the file (maximum 

of nine characters)* 

loc _adr The address at which to locate the Basic I/O 

System* If you want to enter this value as a 
hexadecimal number, you must Include the suffix 
H* The base portion of this value is the base 
portion of the Basic I/O System's entry point* 
The offset portion of the entry point is 0* 

You must specify the entry point in the %J0B 
macro call for the Basic I/O System* 

This command assembles ITABLE.A86 and IDEVCF.A86, links them together 
with other modules containing Basic I/O System code, and locates the 
Basic I/O System at the specified address* It places the located Basic 
I/O System in file lOS on drive FI. It also places the assembly listing, 
link map, and locate map on drive F3 in files lOS.LST, lOS.MPl, and 
I0S.MP2, respectively. 

You must specify a %J0B macro in the system configuration file for the 
Basic I/O System (refer to Chapter 4). In this macro, the entry point 
depends on the address at which you locate the Basic I/O System (CS;0). 
The data segment should be specified as 0 (the Basic I/O System assigns 
its own data segment). 


BASIC 1/0 SYSTEM INITIALIZATION 

The Basic I/O System defines a public symbol in which it returns its 
Initialization status* This symbol, RQ$AIOS$INIT$ERROR, is defined by 
the Basic I/O System as follows: 

DECLARE 

RQ$AIOS$INIT$ERROR STRUCTURE( 

EXCEP$INDEX WORD, 

EXCEP$CODE WORD) PUBLIC; 

If the Basic I/O System Initializes properly, it sets Itself up as an 
Operating System extension and returns a value of 0 in the EXCEP$CODE 
field* If the Basic I/O System does not initialize properly, it sets 
these fields as follows: 

EXCEP$INDEX An index in the Initialization task indicating 

where the task failed* 

EXCEP$CODE The first exception code that the 

Initialization task Incurred* 
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The IRMX 86 Application Loader provides the capability to load lAPX 86 
object files from disk Into memory under the control of the IRMX 86 
Operating System. Application Loader configuration Involves selecting 
parameters of the Application Loader that you wish to Include In your 
application system and selecting the type of loading that the Application 
Loader can do. Tou perform these operations by modifying an 
Intel-supplied Application Loader configuration file and calling an 
Intel-supplied SUBMIT file. The configuration file, LCONFG.P86, Is a 
PL/M-86 source file which Is contained on the Application Loader release 
diskette. As released, this file selects default parameters. To change 
these parameters, you must modify this file, compile It, link It with the 
rest of the Application Loader modules, and locate the Application Loader 
at an absolute address. The Intel-supplied SUBMIT file, LOADER. CSD 
performs the compile, link, and locate operations; as well as selecting 
the type of Application Loader to Include. This chapter describes these 
files. 


MODIFYING LC0NFG.P86 


You can select parameters that are associated with the Application Loader 
by making modifications to LC0NFG.F86. Figure 10-1 lists the portion of 
the released LCONFG.P86 that defines these parameters. 


loaderSconf 1 q: DO; 


DECLARE bufSslze 
DECLARE rdbufssize 


literally '1024'; /♦ BYTES 

LITERALLY '1024'; /♦ BYTES 


♦ / 
♦ / 


DECLARE IbUfSSlze 
DECLARE l$rdbuf$size 


WORD PUBLIC DATACbuf $Slze + 11); 
WORD PUBLIC DATA(rdbuf$size); 


DECLARE L$PEFAULT$NEMP0QL WORD PUBLIC DA1AC50H); /♦ PAGES ♦/ 


END loader$conf 19; 


Figure 10-1. Application Loader Configuration File (LC0NFG.P86) 
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In order to select parameter values, you must change the values specified 
with the LITERALLY staten^nts In LC0NFG.P86. The following paragraphs 
discuss the parameters* 

buf$slze Size of an Application Loader Internal buffer. 

This is the maximum allowable length of the data 
block portion of a data record. Unless you are 
familiar with the formats of data records, you 
should not change this parameter from Its default 
of 1024. 

rdbuf$slze Size of an Application Loader buffer used for 

reading the object file from disk. 

l$default$mempool Default memory pool size. In 16-byte paragraphs. 

This is the size that jobs will have when created 
with the S$L0AD$I0$J0B and A$L0AD$I0$J0B system 
calls. This situation occurs If the mempool 
control was not used when the program being 
loaded was processed by LINK86. This value is 
used for both the maximum and minimum pool sizes. 


COMPILING LCONFG.P86, LINKING AND LOCATING THE LOADER 

After you have made any necessary modifications to the Application Loader 
configuration file, LCONFG.P86, you must compile it and link and locate 
the Application Loader. LOADER. CSD, a SUBMIT file contained on the 
Application Loader release diskette, can be used to perform these 
functions* In order to use this SUBMIT file, you must first prepare your 
diskettes and place them in the proper drives of your development system, 
as explained in the "Linking and Locating the Subsystems" section of 
Chapter 4. Then you can enter the following command: 

SUBMIT :fx:L0ADER(date, loc _adr, code_type, load_job) 
where: 

fx The appropriate disk identifier, indicating the drive 

containing LOADER. CSD. 

date The date on which you submit the file (maximum of nine 

characters). 

loc _adr The address at which to locate the Application 

Loader* If you want to enter this value as a 
hexadecimal number, you must include the suffix H. 

The base portion of this value is the base portion of 
the Application Loader's entry point* The offset 
portion of the entry point is 0. You must specify the 
entry point in the %J0B macro call for the Application 
Loader. 
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code_J:ype The type of code that the Application Loader can 

load* Enter one of the following values for this 
parameter: 

value type of code 

A Absolute code only* 

P Absolute and position independent code 

(PIC)* 

L Absolute, PIC, and load-time loca table 

(LTL) code* 

0 Absolute, PIC, LTL, and overlay code* 

load_Job The types of job loading that the Application Loader 

can perform* Enter one of the following values for 
this parameter: 

value type of job loading 

N No job loading (neither A$LOAD$IO$JOB 

nor S$LOAD$IO$JOB are supported)* The 

Application Loader can handle absolute 
code and overlays only* 

A Asynchronous job loading. 

(S$LOAD$IO$JOB is not supported). 

S Both synchronous and asynchronous job 

loading. 

This command compiles LCONFG.P86, links it together with the rest of the 
Application Loader, and locates the Application Loader at the specified 
address. It places the located Application Loader on drive Fl in file 
LOADER* It also places the compilation listing, link map, and locate map 
on drive F3 in files LOADER. LST, LOADER.MPl, and L0ADER.MP2, respectively. 

You must specify a %JOB macro in the system configuration file for the 
Application Loader (refer to Chapter 4). In this macro, the entry point 
depends on the address at which you locate the Application Loader 
(CS:0). The data segment base should be specified as 0 (the Application 
Loader assigns its own data segment). 
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The Bootstrap Loader Is used to load the IRMX 86 Operating System and/or 
application programs Into memory from mass storage and begin execution of 
the system. The Bootstrap Loader consists of two stages, the first of' 
which must reside In ROM, and the second of which resides on mass 
storage. The first stage contains a device driver (or drivers) which 
loads the second stage into memory. This chapter provides configuration 
parameters for the first stage and the drivers. The second stage Is not 
configurable; It is put on mass storage automatically when the mass 
storage volume Is formatted. 


FIRST STAGE CONFIGURATION 


First stage configuration consists of: 

• Selecting the features that you wish to include in the Bootstrap 
Loader. 

• Listing the characteristics of the possible devices from which the 
Bootstrap loader can read. 

You perform both of these operations by making modifications to a 
Bootstrap Loader first stage configuration file. This file, BS1.A86, is 
an assembly language source file which is contained on the Bootstrap 
Loader release diskette. As released, BS1.A86 defines an example 
configuration. Figure 11-1 lists the portion of BS1.A86 that defines the 
features and devices. To change the configuration of the Bootstrap 
Loader, you must modify this file, assemble it, and link It with the rest 
of the Bootstrap Loader object files and libraries. 

The Bootstrap Loader first stage may also be configured into the iSBC 957B 
monitor. This involves a process very similar to configuring the 
stand-alone Bootstrap Loader. Refer to the USER'S GUIDE FOR THE ISBC 957B 
lAPX 86, 88 INTERFACE AND EXECUTION PACKAGE for details. 
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name bsl 


SincludeC 1 :t>si . inc) 

%console 

%manual 

%auto 

%devlce(fO» 0, devlceinit204, 
%devlce(fl, 1, devicelnit204, 
%devlce(f2, 7, devlceinlt204, 
%devlce(f3, 3, devlceinit204, 
%devlce(dO, 0, devlceinit206, 
%devlce(w0, 0, devlceinit2l5, 
%devlce(w£0, 8, devicelnlt2l5, 
%devlce(w£l, 9, devlcelnlt2l5, 
%device(w£2, 10, deviceinit2l5 
%devlce(w£3, 11, devlceinit215 
%devlce(bO, 0, devlceinit254 , 
%end 


devlceread204) 
deviceread204) 
deviceread204) 
deviceread204) 
deviceread20fi) 
devlceread2l5) 
devlceread215) 
deviceread21 5) 

, deviceread2l5) 
, deviceread215) 
devlceread254) 


Figure 11-1. First Stage Configuration File (BS1.A86) 


The first stage configuration file consists of a series of macro calls 
which define the features and devices. These macros Include: 

%C0NS0LE 

%MANUAL 

I %DEFAULTFILE 

%AUT0 
%DEVICE 
%END 


The file BSl.INC, which is available on the Bootstrap Loader release 
diskette, contains the definitions of all of the macros which you can call 
in the first stage configuration file. BS1.A86 contains an $INCLUDE 
statement for BSl.INC which Includes it in the assembly of BS1.A86. 


%C0NS0LE MACRO 

This optional macro call indicates whether or not the user can supply, 
from the console, the name of ^he file to be loaded. If you Include the 
%C0NS0LE call in your configuration file, the user has the option of 
entering the file name. If you omit the %C0NS0LE call, the Bootstrap 
Loader uses a default file name. The format of the %C0NS0LE call is as 
follows: 

^CONSOLE 
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%MANUAL MACRO 

This optional macro indicates whether or not the user can supply, from the 
console, the name of the device to load from. If you Include the %MANUAL 
call in your system, the user has the option of entering the name of the 
device to load from, as well as the name of the file to be loaded. If you 
omit the %MANUAL call from your system, the user cannot specify the device 
name. 

If you Include the %MANUAL call in the first stage configuration file, the 
%CONSOLE and %AUTO calls are automatically Included, without having to 
specify them. The format of the ^MANUAL call is as follows: 

%MANUAL 


%AUTO MACRO 

This optional macro indicates whether or not the Bootstrap Loader can 
select devices automatically. If you include the ZAUTO call in your first 
stage configuration file and the user does not specify a device name from 
the console, the Bootstrap Loader tries to Initialize, in order, each of 
the devices specified with %DEVICE calls (described in the next section). 
It scans through the devices repeatedly until it successfully initializes 
one. When it does succeed in Initializing a device, it uses that device 
from which to load. If you omit the %AUTO call from your first stage 
configuration file, the Bootstrap Loader can use just one device. The 
format of the %AUTO call is as follows: 

%AUTO 


%DEFAULTFILE MACRO 

This macro spedifles the default file name that is to used by the 
Bootstrap Loader. The format of the %DEFAULTFILE call is as follows: 

%DEFAULTFILE ("default file name") 


%DEVICE MACRO 

This macro defines the possible devices from which the Bootstrap Loader 
can load. You must Include at least one %DEVICE call in your first stage 
configuration file. You can Include more than one if you also include the 
%MANUAL or %AUTO calls. The format of the %DEVICE call is as follows: 

%DEVlCE(name, unit, device$init, devlce$read) 
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where: 


name 


Name of the device from which to load. 


unit 


Unit number of the device. 


devlce$lnlt Address of a procedure that the Bootstrap Loader calls 

to Initialize the device. Intel supplies this procedure 
for ISBC 204, ISBC 206, ISBC 208, ISBC 215, ISBC 220, 
and ISBC 254 devices. To use one of these procedures, 
specify one of the following values: 


device 


value 


ISBC 204 
ISBC 206 
ISBC 208 
ISBC 215 
ISBC 220 
ISBC 254 


DEVICEINIT204 

DEVICEINIT206 

DEVICEINIT208 

DEVICEINIT215 

DEVICEINIT215 

DEVICEINIT254 


devlce$read Address of a procedure that the Bootstrap Loader calls 
to read the device. Intel supplies this procedure for 
ISBC 204, ISBC 206, ISBC 208, ISBC 215, ISBC 220, and 
ISBC 254 devices. To use one of these procedure, 
specify one of the following values: 


device 

value 

ISBC 

204 

DEVICEREAD204 

ISBC 

206 

DEVICEREAD206 

ISBC 

208 

DEVICEREAD208 

ISBC 

215 

DEVICEREAD215 

ISBC 

220 

DEVICEREAD215 

ISBC 

254 

DEVICEREAD254 


%END MACRO 

This macro denotes the end of the first stage configuration file. You must 
Include the %END call as the last statement of the first stage 
configuration file. The format of the %END call Is as follows: 

%END 


DRIVER CONFIGURATION 

Driver configuration consists of providing the elementary device driver 
procedures that the Bootstrap Loader calls when It Initializes and reads 
from the device. You can either Include the routines provided with the 
Bootstrap Loader for the ISBC 204, 206, 208, 215, 220, and 254 devices, or 
you can write your own driver procedures for other devices. 
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INTEL-SUPPLIED PROCEDURES 

Intel supplies elementary device driver procedures which can be used with 
iSBC 204, 206, 208, 215, 220, and 254 devices* In order to Include these 
procedures in your Bootstrap Loader, you can make modifications (if 
necessary) to driver configuration files contained on the Bootstrap 
Loader release diskette, assemble the files, and link them with the rest 
of the Bootstrap Loader object fl!>es and libraries* The following 
sections describe these files* 


ISBC 204 Device Driver 

The file B204*A86 is a device configuration file which places iSBC 204 
device driver procedures in the Bootstrap Loader* This file is an 
assembly language source file which is contained on the Bootstrap Loader 
release diskette* Figure 11-2 lists the portion of B204*A86 that 
Includes the driver procedures* 


Slncludef :f2tb204.1nc) 
%b204(0A0H, 128, 26) 


Figure 11-2* Driver Configuration File (B204*A86) 


B204*A86 contains two statements, an $INCLUDE statement and a ZB204 macro 
call* The $INCLUDE statement Includes file B204*INC in the assend>ly of 
B204.A86* B204*INC contains the definition of the ZB204 macro and is 
available on the Bootstrap Loader release diskette* The ZB204 call 
causes the configuration of the ISBC 204 driver routines* You can modify 
the ZB204 call to reflect your system* The format of the ZB204 call is 
as follows: 

ZB204(lo_base, sector_slze, track__size) 


where: 

lo_base 

sector_slze 
track size 


Base I/O port number which is selected on the iSBC 204 
board* 

Sector size of the device in bytes* 

Track size of the device in sectors* 
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The ISBC 204 device driver uses the following values for drive parameters: 
parameter value 


step rate 

head settling time 
head load time 


25 milliseconds 
20 milliseconds 
60 milliseconds 


These values refer to 8-lnch drlves< The values are sufficient for most 
flexible diskette drives* 


ISBC 206 Device Driver 

The file B206*A86 Is a device configuration file which places ISBC 206 
device driver procedures In the Bootstrap Loader. This file Is an 
assemblj language source file which Is contained on the Bootstrap Loader 
release diskette. Figure Il'-3 lists the portion of B206.A86 that 
Includes the driver procedures* 


sincludeC :f2:b206,lnc) 
%b206(068H) 


Figure 11-3. Driver Configuration File (B206.A86) 


B206.A86 contains two statements, an $1NCLUDE statement and a ZB206 macro 
call* The $1NCLUDE statement Includes file B206.1NC In the assemblj of 
B206.A86. B206.1NC contains the definition of the TB206 macro and Is 

available on the Bootstrap Loader release diskette* The ZB206 call 
causes the configuration of the ISBC 206 driver routines* You can modify 
the XB206 call to reflect your system* The format of the TB206 call Is 
as follows: 

ZB206(lb__base) 


where: 

lo_base Base I/O port number which Is selected on the ISBC 206 

board* 
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ISBC 208 Device Driver 

The file B208.A86 Is a device configuration file which places ISBC 208 
device driver procedures In the Bootstrap Loader. This file Is an 
assembly language source file which Is contained on the Bootstrap Loader 
release diskette. Figure 11-4 lists the portion of B208.A86 that 
Includes the driver procedures. 


$include(:fl:b208,lncj 

%b208(000H) 


Figure 11-4. Driver Configuration File (B208.A86) 


B208.A86 contains two statements, an $INCLUDE statement and a ZB208 macro 
call. The $INCLUDE statement Includes file B208.1NC In the assembly of 
B208.A86. B208.1NC contains the definition of the ZB208 macro and Is 

available on the Bootstrap Loader release diskette. The ZB208 call 
causes the configuration of the ISBC 208 dlrver routines. You can mqdlfy 
the ZB208 call to reflect your system. The format of the ZB208 call Is 
as follows: 

ZB208(1o base) 


where: 

lo_base Base I/O port number which Is selected on the ISBC 208 

board. 


ISBC 215/220 Device Driver 

The file B215.A86 Is a device configuration file which places ISBC 215 or 
ISBC 220 device driver procedures In the Bootstrap Loader. This file Is 
an assembly language source file which Is contained on the Bootstrap 
Loader release diskette. Figure 11-5 lists the portion of B215.A86 that 
Includes the driver procedures. 
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BincludeC :f2:b?l5.1nc) 

%b2l5(70H, 256, 2, 0, 9, 1024, 5) 


Figure 11-5. Driver Configuration File (B215.A86) 


B215.A86 contains two statements, an $INCLUDE statement and either a 
%B215 macro call or a ZB220 macro call. The $INCLUDE statement Includes 
file B215.INC In the assemblf of B215.A86. B215.INC contains the 
definitions of the ZB215 and ZB220 macros and Is available on the 
Bootstrap Loader release diskette. The ZB215 call causes the 
configuration of the ISBC 215 driver routines. The %B220 call (with the 
same parameter values) causes the configuration of the ISBC 220 driver 
routines. You can modify either of these calls to reflect your system. 
The format of the two calls are as follows: 

ZB215(wakeup, cylinders, flxed_heads, removable_heads , sectors, 
dev__gran, alternates) 

or 

ZB220(wakeup, cylinders, flxed_heads, removable_heads, sectors, 
dev _gran, alternates) 


where: 

wakeup 

cylinders 


Base address of the wakeup port 

Number of cylinders on the disk drive or drives. All 
drives used by the Bootstrap Loader must have the same 
characteristics. 


f Ixed^eads 

Number 

Of 

removable_- 

Number 

of 

heads 



sectors 

Number 

of 

dev_gran 

Number 

of 

alternates 

Number 

of 
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iSBC 254 Device Driver 

The file B254.A86 is a device configuration file which places iSBC 254 
device driver procedures in the Bootstrap Loader. This file is an 
assembly language source file which is contained on the Bootstrap Loader 
release diskette. Figure 11-6 lists the portion of B254.A86 that 
Includes the driver procedures. 


$lnclude( :f 2:b?54.1nc) 
%b254(040H, 64, 1, 8192) 


Figure 11-6. Driver Configuration File (B254.A86) 


B254.A86 contains two statements, an $1NCLUDE statement and a ZB254 macro 
call. The $1NCLUDE statement Includes file B254.1NC in the assembly of 
B254.A86. B254.1NC contains the definition of the ZB254 macro and is 

available on the Bootstrap Loader release diskette. The ZB254 call 
causes the configuration of the ISBC 254 driver routines. You can modify 
the ZB254 call to reflect your system. The format of the ZB254 call is 
as follows: 


ZB254(lo_base, 

where: 

lo_base 

dev _gran 
nuffl_boards 
board size 


dev_gran, num_boards, board_slze) 

Base I/O port number which is selected on the ISBC 254 
board. 

Page size, in bytes. 

Reserved field which must be set to 1. 

Size, in pages, of the ISBC 254 board. 


USER-SUPPLIED PROCEDURES 

If you have devices other than ISBC 204, 206, 208, 215, 220, or 254 
devices that you want to use with the Bootstrap Loader, you aust write 
device driver routines for these devices, specify the addresses of these 
routines in the first stage configuration file, assemble them, and link 
them to the rest of Bootstrap Loader object files and libraries* You 
must supply the following two procedures for each type of device that you 
wish to support: 
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device initialization This procedure must determine whether the 

device is ready and then perform any 
necessary Initialization* 

device read This procedure must read data from the 

device. 

The Bootstrap Loader expects each of these procedures to follow the 
PL/M-86 large model of computation, be of type FAR, and use 32-bit 
pointers. If you are coding your routines in PL/M-86, you should specify 
the ROM control in order to permit the Bootstrap Loader to function in 
ROM. The iRMX 86 LOADER REFERENCE MANUAL describes how to create these 
procedures . 

You can use any names you want for your device Initialization and device 
read procedures. However, you must specify the names of the procedures 
in the %DEVICE macro call for the device, when you create the first stage 
configuration file. 


ASSEMBLING THE CONFIGURATION FILES, LINKING AND LOCATING THE BOOTSTRAP 
LOADER 


After you have made any necessary modifications to the Bootstrap Loader 
configuration files, BS1.A86, B204.A86, B206.A86, B208.A86, B215.A86, and 
B254.A86 and have created any necessary device driver procedures, you 
should assemble these files and link and locate the Bootstrap Loader. 
BSl.CSD, a SUBMIT file contained on the Bootstrap Loader release 
diskette, can be used to perform these functions. In order to use this 
SUBMIT file, you must first prepare your diskettes and place them in the 
proper drives of your development system, as explained in "Linking and 
Locating the Subsystems” section of Chapter 4. You should also examine 
the configuration files to make sure that the $INCLUDE statements contain 
the proper disk identifiers. Then you can enter the following command: 

SUBMIT :f x:BSl(date, rom_loc _addr, ram_loc _addr) 
where: 

fx The appropriate disk identifier, indicating the drive 

containing BSl.CSD 

date The date on which you submit the file (maximum of nine 

characters). 

rom_loc _addr The address at which to locate the first stage of the 

Bootstrap Loader (the CODE segment). This address 
specifies the location of the ROM-resident portion of 
the Bootstrap Loader. If you want to specify a 
hexi decimal value for this parameter, you must use the 
suffix H (and the prefix 0, if the value begins with a 
letter). 
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ram_loc_addr The address at which to locate the STACK, DATA, and 
BOOT segments of the Bootstrap Loader. This address 
specifies location of the RAM-resident portion of the 
Bootstrap Loader. If you want to specify a 
hexidecimal value for this parameter, you must use the 
suffix H (and the prefix 0, if the value begins with a 
letter). 

If you have written and compiled your own device driver procedures, you 
should modify BSl.CSD in order to link these procedures in with the 
remainder of the Bootstrap Loader. To do this, place the names of your 
device driver object files in the L1NK86 input list immediately before 
the line containing: 

:Fl:bsl.lib & 


If you plan to run the Bootstrap Loader on an iAPX 86,88-based 
microcomputer system that does not include an iSBC 957A/B monitor and you 
wish to use the console for input /output (%MANUAL or %C0NS0LE calls 
present in the configuration file), you must supply procedures that read 
from and write to the console. The Bootstrap Loader release diskette 
includes a PL/M-86 source file which contains procedures to do this. You 
can examine this file, BCICO.P86, modify the procedures to suit your 
needs, compile it, and link it to the rest of the Bootstrap Loader object 
files and libraries. You can also use these routines as examples if you 
need to supply console input and console output functions for any of your 
other routines. 

To include the read and write procedures as part of your Bootstrap 
Loader, you should add three lines to the BSl.CSD SUBMIT file. Add the 
first two lines immediately before the LINK86 statement, in order to 
compile the routines. These line are: 

PLM86 :F1:BCIC0.P86 LARGE ROM 0PTIMIZE(3) & 

PRINT(:F1:BCIC0.LST) DATE(%0) CODE 


Add the third line immediately following the LINK86 invocation, in order 
to link the routines in with the remainder of the Bootstrap Loader. This 
line is: 

:F1:BCIC0.0BJ, & 

If you include this line, LINK86 will generate a warning message similar 
to: 

WARNING 25: EXTRA START ADDRESS IGNORED 
This is a normal message; it does not indicate an error condition. 
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When locating the Bootstrap Loader, the location of the CODE segment 
determines which locations of ROM the Bootstrap Loader needs* The 
location of the STACK, DATA, and BOOT segments determines which locations 
of RAM the Bootstrap Loader needs* (The Bootstrap Loader reads Its 
second stage Into the BOOT segment during Initialization*) You do not 
have to reserve memory for these RAM segments with %SAB macro calls* 

After you have located the Bootstrap Loader, you should burn the code 
segment Into PROM* The second stage portion of the loader will be placed 
on disk automatically, when you use the Files Utility or the Human 
Interface to format the disk* Refer to the IRMX 86 INSTALLATION GUIDE 
for further Information concerning the Files Utility and the IRMX 86 
HUMAN INTERFACE REFERENCE MANUAL for Information concerning the Human 
Interface* 


11-12 



CHAPTER 12. CONFIGURING THE EXTENDED I/O SYSTEM 


Extended I/O System configuration involves the following three operations 

• Selecting the system calls of the Extended I/O System that you 
want to include in your application system and discarding the 
rest. 

• Selecting the logical devices that you want the Extended I/O 
System to Initialize. 

• Selecting I/O jobs that you want the Extended I/O System to 
create during system initialization. 


You perform all of these operations by making modifications to the 
following files, all of which are contained on the Extended I/O System 
release diskette: 


File 

STABLE. A86 
EDEVCF.A86 
EJOBCF.A86 


Purpose 

System call configuration 
Logical device configuration 
I/O job configuration 


Figure 12-1 Illustrates the structure of these files. As released, these 
files define the full complement of system calls, as well as a standard 
group of logical devices and jobs. To eliminate system calls from your 
Extended I/O System, or make changes to the logical device or job 
configuration, you must make changes to these files, assemble them, link 
them to the rest of the Extended I/O System object files and libraries, 
and locate the Extended I/O System at an absolute address. The remainder 
of this chapter describes these processes. 
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Figure 12-1. Structure of Extended I/O System Configuration Files 
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SELECTING SYSTEM CALLS (ETABLE.A86) 


ETABLE.A86 consists of a series of macro calls which correspond In n^e 
to the system calls of the Extended I/O System* Each macro gives 
directions to the assembler to Include code for that system call In the 
Extended I/O System* To exclude a system call from your Extended I/O 
System, delete the metacharacter (%) of the associated macro call, and 
replace It with the comment character (;)* By doing this, you change the 
macro call Into a comment and prevent the assembler from evaluating It* 

The file ETABLE*MAC, which Is available on the Extended I/O System 
release diskette, contains the definitions of all macros called In 
ETABLE*A86* ETABLE*A86 contains an $INCLUDE statement for ETABLE*MAC, 
which Includes It In the assembly of ETABLE*A86. 

Figure 12-2 lists the released ETABLE*A86 file* If you do not modify 
this file. It will Include the full complement of Extended I/O System 
system calls In your application system* 


NAME' EIABLt 
SlNCLUDt(:F2:ETABLF.MAC) 


JOB INTFKFACe 

ftKOCREAIFlOJOB 

%ROt'XITinjOB 

configuration INierfaCE 

%hologtcalattachdevice 

%rologicaldetachdevice 

SYNCHRONOUS INTERFACE 

tRQBCREATEFlLE 

tRQSAITACHElLE 

%rqsdeletecqnnection 

%R0SL00KUPC0NNECT10N 
%R0SCATAL0GC0NNECTI0N 
*ROSUNCATALOGCONNECTION 
%R0SCREaTED1 RECTORY 

%hosdeletefile 


Figure 12-2* System Configuration File (ETABLE*A86) 
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%rosremanefile 

%ROSCH«NCCACCESS 

tROSOPFN 

%RQSCLOSE 

%ROSREAOMOVE 

%roswritemovc 

tROSSEEK 

%ROSTRUNCAT£FILE 

%R0SGETFILE5TATUS 

%R0SGETC0NN£CII0NSTATUS 

%R0SSPECIAL 

END 


Figure 12-2. System Call Configuration File (ETABLE.A86) (continued) 


SELECTING LOGICAL DEVICES (EDEVCF.A86) 


EDEVCF.A86 consists of a series of macro calls that associate logical 
names with physical device-units. When the Extended I/O System Is 
Initialized, It creates Logical Device Objects for the devices and 
catalogs these objects In the root job's object directory under the 
specified logical names. The first time these logical names are used as 
the prefix portions of path names, the Extended I/O System creates device 
connections. 

One of the macros called in EDEVCF.A86 Is the ZDEV_INFO_BLOCK macro. The 
format of a call to this macro Is very similar to the format of the 
LOGICAL$ATTACH$DEVICE system call (described In the IRMX 86 SYSTEM 
PROGRAMMER'S REFERENCE MANUAL). The format Is as follows: 

ZDEV_INFO_BLOCK( 'log_name', 'dev_name', flle_driver) 
where: 

logjiame Logical name under which the device-unit Is to be 

cataloged In the root object directory. This name can 
consist of one to twelve characters. You must enclose 
this name In single quotes. 

dev_name Name of the devlce*-unlt to be assigned a logical 

name. Use the name associated with the DUIB of this 
device-unit for this parameter. (DUIBs are described 
in the "Oevlce-Unlt Information Block" section of 
Chapter 9.) You must enclose this parameter In single 
quotes. 
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file_driver Type of files which can reside on this device* 

Possible values Include: 

PHYSICAL 

STEEAM 

NAMED 

The other macro called in EDEVCF*A86 Is the ZEND _J)EV_C0NF1G macro* The 
format of this macro Is: 

ZEND_DEV_CONFIG(buf f er_s is# ) 
where: 

buffer_size Suggested size of the buffers that the Extended I/O 

System uses when It transfers Information to and from 
files* The actual buffer size Is the largest multiple 
of the device granularity that does not exceed the 
buffer_slze value* If the device granularity for a 
device exceeds this value, then the buffer created 
when a file Is opened will be equal In size to Its 
device granularity* The device granularity Is a Basic 
1/0 System configuration parameter (refer to Chapter 

9 )* 

A call to this macro specifies the buffer size and designates the end of 
the logical device configuration * 

The file EDEVCF*MAC, which Is available on the Extended 1/0 System 
release diskette, contains the definitions of the macros called In 
EDEVCF*A86* EDEVCF*A86 contains an $1I«:LUDE statement for EDEVCF*MAC, 
which Includes it in the assembly of EDEVCF*A86* 

Figure 12-3 lists EDEVCF*A86 as It Is released with the Extended I/O 
System* This file contains ZDEV_INF0_BL0CK macro calls for several 
commonly used device-units* You should modify this file to reflect your 
hardware environment* 


name 

EDEVCF 


CGROUP 

GROUP 

CODE 



assume CS : CGROUP 


SlNCLUDE(:F2:EDEVCr.>*AC) 


t BYTE-BUCKET 
! 

%DEV-INF0«BL0CK( 'BB' , 'BB' , PHYSICAL) 


Figure 12-3* Logical Device Configuration File (EDEVCF.A86) 
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t 


t 


TERMINAL 

%D£V.INF0.BL0CK( 'TO', 'TO', PHYSICAL) 
SHUGART 204, UNIT 0, DRIVE 0 

%DEV.lNFCJ_aLaCK( 'FO' , 'FO ' ,N AMEU) 

SHUGART 204, UNIT 1, DRIVE 1 

%DEV«INF0.8L0CK( 'FI ', 'FI ' ,NAMED) 

218 WINCHESTER FLOPPY SS/SD, UNIT 0, DRIVE 0 
%DEV.InFU_BL0CK( 'WFO', 'WFO' , NAMED) 

218 WINCHESTER FLOPPY SS/SD, UNIT 1, DRIVE 1 
%DtV.TNFD.ttLOCK('WFl ' , 'WFl ' , NAMEu) 

STRFAM 

%DEV.INFU.8L0CK( 'STREAM', 'STREAM', STREAM) 
%END.DEV.C0NFIG(1024) 

END 


Figure 12-3. Logical Device Configuration File (EDEVCF.A86) (continued) 


SELECTING I/O JOBS (EJOBCF.A86) 


EJOBCF.A86 consists of a series of macro calls that direct the Extended 
I/O System to create I/O jobs at system Initialization time. The I/O 
jobs created become children of the Extended I/O System Initialization 
job. The macros called in EJOBCF.A86 are: 


%I0_USER 

%IO_JOB 

%END 10 JOB CONFIG 
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The file EJOBCF.MAC, which is available on the Extended I/O System 
release diskette, contains the definitions of all macros called in 
EJOBCF.A86. EJOBCF.A86 contains an $INCLUDE statement for EJOBCF.MAC, 
which includes it in the assembly of ETABLE.A86. Figure 12-4 lists 
EJ0BCF.A86 as released with the Extended I/O System. This file contains 
macro calls for one typical job. You must modify this file to reflect 
the needs of your application system. 

If you want to include the Human Interface in your configured system, you 
must modify EJ0B.A86 to specify the Human Interface as an I/O job. Refer 
to Chapter 13 for further information. 


NA»<E Fjnarf 

CGRQUP GROUP CODE 

ASSUME CS : cgroup 

SINCLUDEt;F2: EJOBCF.MAC) 

• USER 'WORLD' DEFINITION 

%TU_USER( 'wOkLD' , OFFFFH) 

9 

: ETOS TEST JOB 

%T O.JOb ( 'TO ','»nKLu',26OH,0FFFFH,0:0,0,n,tbS,lbO0:0,lA00, 0:0, 1200,0) 
%FND_TO-jnti-CONFlG(4o) 
fnd 


Figure 12-4. I/O Job Configuration File (EJOBCF.A86) 


%I0_USER MACRO 

The %I0_USER macro defines users that are later specified in the %I0_J0B 
calls. You must define each user with %I0_USER before you refer to it, 
and you must include one %I0_USER macro for each object that you define. 
The format of the call to %I0_USER is as follows: 

%I0_USER( ’user_name ' , user_id) 

where: 

user_name Name of the user (1 to 12 characters). This name must 

be enclosed in single quotes. 
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user_ld A 16-bit value that specifies the id of of the user . 

Your EJ0BCF.A86 file must contain at least one ZIO_USER call which 
defines a user whose name is WORLD and whose id is OFFFFH. The released 
version of EJOBCF.A86 contains such a call* 


ZIO_JOB MACRO 

The %IO_JOB macro defines the I/O jobs to be created. You must include 
one macro call for each I/O job that you want the Extended I/O System to 
create* The format of the call to the %IO_JOB macro is very similar to 
the format of the CREATE$IO$JOB system call* A short description of the 
%IO_JOB parameters is Included in this section^ but for a complete 
description refer to the description of the CREATE$IQ$JOB system call in 
the IRMX 86 EXTENDED I/O SYSTEM REFERENCE MANUAL. The format of the call 
to %IO_JOB is as follows; 

^10_J0B( 'default_pref ix', *default_user ' , pool_mln, pooljnax, 
excep_handler _addr, excep_mode, job _flags, task_prlor, 
task_start addr, data_segment, stack_addr, stack_size, 
task flagsT 


where: 


default jprefix 


default user 


pool min 


pool max 


excep_handler_- 

addr 


Logical name specifying the default prefix for 
the job* If you omit this parameter, the default 
prefix for the Extended I/O System's 
Initialization job is used* This parameter must 
be enclosed in single quotes* 

Name of the default user for this job* You must 
have previously defined this user name with a 
call to %IO_USER* This parameter must be 
enclosed in single quotes* 

Minimum allowable size of the new job's memory 
pool, in 16-byte paragraphs* The Extended I/O 
System uses this parameter as the initial size of 
the memory pool for the new job* 

Maximum allowable size of the new job's memory 
pool, in 16-byte paragraphs* 

Hexadecimal pointer to the new job's default 
exception handler, in the form base: offset* A 
value of 0:0 Indicates that the job uses the 
Extended I/O System exception handler* (The 
Extended I/O System exception handler is declared 
at system configuration time in the %J0B macro* 
Refer to the ”%J0B Macro" section of Chapter 4 
for further information.) 
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excep_mode Encoded value which tells the Extended I/O System 

when to pass control to the exception handler. 
Encode this value as follows: 

Value Control Passes to Exception Handler 

0 Never 

1 On programmer errors only 

2 On environmental conditions only 

3 On all exceptional conditions 

job_flags Information that tells the Nucleus whether to 

validate objects used as parameters in system 
calls* Bits in this word are interpreted as 
follows: 

bit Meaning 

15-2 Reserved. 

1 If set to 0, the Nucleus validates 

objects used as parameters. If 
set to 1, the Nucleus performs no 
validation. 

0 Reserved. 

task^prior Priority of the initial task in the newly created 

job. Specify a value in the range 0 to 255 
decimal. A value of zero for this parameter 
indicates that the initial task has a priority 
equal to the maximum priority of the initial job 
of the Extended I/O System. 

task__start_addr Hexadecimal pointer to the first instruction of 

the new job’s initial task, in the form 
base:offset. 

data^segment Value to which the initial task’s DS and ES 

registers are initialized. A value of zero 
Indicates that the initial task assigns the data 
segment. 

stack _addr Hexadecimal pointer (in the form basexoffset) of 

the stack for the initial task. A value of 0:0 
causes the Nucleus to allocate a stack to the 
task and initialize the SS register to the base 
address of this segment and the SP register to 
the value of the stack^size parameter. It is 
recommended that you specify 0:0 for this 
parameter. This permits dynamic stack allocation. 

stack^size Size in bytes of the stack for the initial task. 
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task_flags A Word that specifies whether the new job's 

initial task contains floating-point 
instructions* The bits (where bit 15 is the 

high-order bit) have the following meanings: 

bit meaning 

15-1 Reserved* 

0 If set to 1, the initial task uses 

floating-point instructions* 

These instructions require the 
8087 NDP for execution* If set to 
0, the initial task does not 
contain floating-point 
instructions* 


%END_I0_J0B_C0NFIG MACRO 

The %END_IO_JOB_CONFIG macro indicates the end of I/O job configuration. 
You should place this macro call at the end of EJOBCF.A86* The format of 
the call to this macro is as follows: 

%END_I0_J0B_C0NFIG(dir_s ize ) 
where: 

dir_slze Maximum allowable number of entries in the object 

directories of I/O jobs* A value of zero indicates 
that no object directories are to be created for I/O 
jobs* 


ASSEMBLING THE CONFIGURATION FILES. LINKING AND LOCATING THE EXTENDED I/O 
SYSTEM 


After you have made any necessary modifications to the Extended I/O 
System configuration files, ETABLE.A86, EDEVCF.A86, and EJOBCF.A86, you 
must assemble them and link and locate the Extended I/O System* 

EIOS.CSD, a SUBMIT file contained on the Extended I/O System release 
diskette, can be used to perform these functions* In order to use this 
SUBMIT file, you must prepare your diskettes and place them in the proper 
drives as explained in the "Linking and Locating the Subsystems” section 
of Chapter 4* You should also examine STABLE. A86, EDEVCF.A86, and 
EJOBCF.A86 to make sure that the $INCLUDE statements contain the proper 
disk identifiers* You can then enter the following command: 

SUBMIT :fx:EI0S( date, loc_adr) 
where : 

fx The appropriate disk identifier, indicating the drive 

containing EIOS.CSD* 
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date The date on which you submit the file (maximum of nine 

characters)* 

loc^adr The address at which to locate the Extended I/O 

System* If you want to enter this value as a 
hexadecimal number, you must include the suffix H. 

The base portion of this value is the base portion of 
the Extended I/O System’s entry point* The offset 
portion of the entry point is 0. You must specify the 
entry point in the %J0B macro call for the Extended 
I/O System* 

This command assembles ETABLE.A86, EDEVCF*A86, and EJ0BCF*A86, links them 
together with the other modules of the Extended I/O System, and locates 
the Extended I/O System at the specified address. It places the located 
Extended I/O System in file EIOS on drive Fl. It also places the 
assembly listing, link map, and locate map on drive F3 in files EIOS.LST, 
EIOS.MPl, and EI0S.MP2, respectively* 

You must specify a %J0B macro in the system configuration file for the 
Extended I/O System (refer to Chapter 4)* In this macro, the entry point 
depends on the address at which you locate the Extended I/O System 
(CS:0). The data segment should be specified as 0 (the Extended I/O 
System assigns its own data segment)* 


EXTENDED I/O SYSTEM INITIALIZATION 


The Extended I/O System defines a public symbol, RQ$EI0S$INIT$ERR0R, in 
which it returns its initialization status* If the Extended I/O System 
initializes properly, it attaches all logical devices specified in the 
configuration file (EDEVCF. A86), sets itself up as an operating system 
extension, and sets RQ$EI0S$INIT$ERR0R to zero* If the Extended I/O 
System does not initialize correctly, it sets RQ$EI0S$INIT$ERR0R to a 
nonzero value* 

Once the initialization is complete, users can create and attach files on 
the devices specified in EDEVCF *A86 (unless they are off-line, in which 
case an exceptional condition code is returned)* If one of these devices 
is switched from on-line to off-line, the Extended I/O System 
automatically marks all synchronous connections to that device as invalid 
(returns the E$BAD$SYNC$C0NN condition code) and detaches the device* 

When the unit is switched back on, the Extended I/O System automatically 
attaches it the first time a user tries to create or attach a file on 
it* The Extended I/O System performs this service only for all devices 
that it attaches* 
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Human Interface configuration involves the following operations: 

• Designating prefixes and subpaths for the logical names required 
by the Human Interface 

• Specifying the Human Interface sign--on 

• Specifying the maximum number of characters in a command name 

• Specifying the list of directories that the Human Interface 
searches when it tries to load a command. 

You perform these operations by making modifications to an Intel-supplied 
Human Interface configuration file. This file, HC0NFG.P86, is a PL/M-86 
source file which is contained on the Human Interface release diskette. 

As released, HCONFG.P86 defines a default Human Interface. To make 
changes, you must modify HC0NFG.P86, compile it, link it with the rest of 
the Human Interface object files and libraries, and locate the Human 
Interface at an absolute address. The following sections describe this 
configuration process. 


MODIFYING HC0NFG.P86 


HC0NFG.P86 consists of a series of PL/M-86 DECLARE statements which 
identify the characteristics of the Human Interface. Figure 13-1 lists 
the portion of the released HCONFG.P86 that you can modify. To change 
the configuration information, you must modify the values associated with 
the variables in the DECLARE statements. The following paragraphs list 
the variables you can change. 
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hconfg: DO; 


/♦ path names that tolil reoresent default directories ♦/ 

DECLARF 

Hssystem$dl rectoryC*) bYlE PUBLIC DATAf 10, ' :FOiSYSTEM' ) , /♦ rsYSTE 

HSprogSdlrectoryf ♦) bYiF PUBLIC DATa(8 , ' ;F0;PRnG') , /♦ rPPOC; 

Hsdefauitsdir (♦ J BYTE PUBLIC DATA ( 4 , ' : FO ; ' ) , /* :$: ♦/ 

H$work$dlrectory(*) BYTE PUbLIC DaTaCB, ':FO;work'); /♦ ;»<ORK: 


DECLARF 

H$sianSon(»J PifTE PUBLIC DATA( 1 5, 'IR^X 86 HI VI. O'), 

H$comniand$name$max WORD PUBLIC DATAcSO), /♦ command name max size 

HSoref IxesC*) BYlF PUBLIC DATAC2, /♦ number of prefixes ♦/ 
6 ,':prhg:', /♦ first prefix ♦/ 

R , ' : Si^TFh : ' ) ; /♦ second prefix ♦/ 


I Figure 13-1. Human Interface Configuration File (HCONFG. P86) 

The first four variables define paths for which the Human Interface 
assigns logical names. These paths are specified in the form of 
STRINGS. The first portion of each string (the length) is a number which 
equals the number of characters in the second portion of the string. The 
second portion of the string consists of the prefix and subpath. 

Maintain this format when modifying the variables. If you specify a 0 
for the length of any string, the Human Interface will not create the 
corresponding logical name. 

H$SYSTEM$DIRECTORY(*) A BYTE array containing a STRING which 

defines the prefix and subpath of a 
directory that the Human Interface 
associates with logical name : SYSTEM;. 

H$PROG$DIRECTORY(*) A BYTE array containing a STRING which 

defines the prefix and subpath of a 
directory that the Human Interface 
associates with logical name :PR0G: . 

H$DEFAULT$DIR(*) A BYTE array containing a STRING which 

defines the prefix that the Human Interface 
associates with logical name ;$:. 
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H$WORK$DIRECTORY(*) A BYTE array containing a STRING which 

defines the prefix that the Human Interface 
associates with logical name :WORK;. 

The following variable is also specified in the form of a STRING. It 
defines the Human Interface sign-on. 

H$SIGN$ON(*) A BYTE array containing a STRING which 

defines the Human Interface slgn-on 
characters. These characters are displayed 
on the user terminal when the Human 
Interface begins running. 

The next variable defines the number of characters in a command name. 

H$COMMAND$NAME$MAX A WORD specifying the maximum number of 

characters in a command name. This includes 
the prefix and subpath portions of the 
command name . 

The following variable defines directories that the Human Interface 
searches when looking for a user-specified file. These directories are 
specified in the form of a STRING table. A STRING table is a BYTE array 
whose first byte specifies the number of strings in the table. The 
remaining bytes of the STRING table specify the actual STRINGs . 

H$PREFIXES(*) A BYTE array* in the form of a STRING table, 

indicating the directories that the Human 
Interface searches, in order, when looking 
for commands. As many as 255 directories 
can be specified in this STRING table. The 
STRINGS can contain either logical names 
(for existing files) or pathnames. When the 
Human Interface user specifies a pathname 
that does not begin with ($) or (:), the 
Human Interface appends the pathname from 
the command line to the end of the first 
directory name in the STRING table. If the 
file this created is not found, the Human 
Interface repeats the process for the 
remaining directories. 

If a directory name in the STRING table 
includes a pathname (that is, it is more 
than just a logical name), it must include 
the (/) as the last character. The (/) is 
needed because the Human Interface appends 
the user-specified file name directly to the 
end of the directory name. 
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HCONFG.P86 also contains definitions of variables that are not described 
in this manual. These variables are defined in the configuration file to 
allow for future expansion of the configuration options. They are not 
currently user selectable. Do not modify the value of any variable that 
is not described in this section. 


COMPILING HCQNFG.P86, LINKING AND LOCATING THE HUMAN INTERFACE 

HI.CSD, a SUBMIT file contained on the Human Interface release diskette, 
can be used to link and locate the Human Interface. In order to use this 
SUBMIT file, you must first prepare your diskettes and place them in the 
proper drives of your development system, as explained in the "Linking 
and Locating the Subsystems** section of Chapter 4. Then you can enter 
the following command: 

:fx:HI( date, loc_adr) 


The appropriate disk identifier, indicating the drive 
containing HI.CSD. 

The date on which you submit the file (maximum of nine 
characters). 

The address at which to locate the Human Interface. 

If you want to enter this value as a hexadecimal 
number, you must include the suffix H. The base 
portion of this value is the base portion of the Human 
Interface subsystem entry point. The offset portion 
of the entry point is 0. You must specify the entry 
point in the %I0_J0B macro call for the Human 
Interface. You specify this macro call during 
Extended I/O System configuration. 

This command compiles HC0NFG.P86, links together the modules that make up 
the Human Interface, and locates the Human Interface at the specified 
address. It places the located Human Interface in file HI on drive FI. 

It also places the link and locate maps on drive F3 in files HI.MPl and 
HI.MP2 respectively. 

Unlike the other iRMX 86 subsystems, the Human Interface does not require 
a %J0B macro in the system configuration file. Instead, the Extended I/O 
System must create the Human Interface as an I/O job. To ensure that 
this process takes place, you must include an %I0^J0B macro for the Human 
Interface in the Extended I/O System configuration file (EJ0BCF.A86). 
Refer to Chapter 12 for more information about the %I0^J0B macro. In 
this %IO>_jJOB macro, the entry point depends on the address at which you 
locate the Human Interface (CS:0). The data segment base should be 
specified as 0 (the Human Interface Initializes its own data segment). 


SUBMIT 

where: 

fx 

date 
loc adr 


13-4 



CONFIGURING THE HUMAN INTERFACE 


HUMAN INTERFACE REQUIREMENTS 


In order to run the Human Interface, you must include the following 
iRMX 86 subsystems in your application system. 

Nucleus 

Debugger or Terminal Handler 
Basic I/O System 
Extended I/O System 
Application Loader 
Human Interface 

The Nucleus, Basic and Extended I/O Systems, and the Application Loader 
must be configured with the system calls required by the Human 
Interface. Appendix C lists these requirements. The following sections 
outline any additional requirements of the subsystems. 


TERMINAL HANDLER OR DEBUGGER REQUIREMENTS 

The Human Interface communicates to the terminal via the Basic I/O 
System, which in turn uses the Terminal Handler (or the Debugger’s 
Terminal Handler). In order for this to happen, the Basic I/O System 
requires that a Terminal Handler with input and output mailbox names 
RQTHNORMIN and RQTHNORMOUT, respectively, be present in the application 
system. These mailbox names are configuration options of the Terminal 
Handler. Refer to Chapter 7 for further information. The Basic I/O 
System is unable to communicate through a Terminal Handler with different 
input and output mailbox names. 

The Human Interface library, HI. LIB, contains a module that implements 
control-C semantics. To use this module, you must link it to the 
Debugger or the Terminal Handler, depending on which you use with the 
Human Interface. To link this module, modify the Terminal Handler or 
Debugger SUBMIT file (MTH.CSD or DB.CSD) to include the following line: 

: f x: HI .LIB (HCONTC ) , & 

Place this line in the LINK86 input list in the place designated for the 
control-G semantics file, as indicated in Chapters 7 and 8. 


BASIC I/O SYSTEM REQUIREMENTS 

The Human Interface uses the Basic I/O System to perform I/O to secondary 
storage devices. In order to run the Human Interface, the Basic I/O 
System must contain the following file drivers: 

physical 

stream 

named 
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Ensure that these file drivers are selected In the Basic I/O System 
configuration file (ITABLE.A86). Refer to Chapter 9 for information. 

The Basic I/O System must also contain DUIBs for the devices used by the 
Human Interface* In particular, the IDEVCF.A86 configuration file must 
contain DUIBs for devices with the following device nan^s: 

TO Terminal device 

BB Byte bucket device 

STREAM Stream file device 

The released version of IDEVCF.A86 contains DUIBs for these devices. You 
must ensure that IDEVCF.A86 contains DUIBs for any other devices used by 
the Human Interface, such as disk drives. 

The Basic I/O System must also contain device drivers for each of the 
devices used by the Human Interface. In particular, you must ensure that 
IDEVCF.A86 includes the On Board USART driver to enable the I/O System to 
communicate with the terminal via the Terminal Handler (or the Debugger's 
Terminal Handler). 


EXTENDED I/O SYSTEM REQUIREMENTS 

The TO, BB, and STREAM devices must be logically attached when the Human 
Interface starts processing. Therefore, the Extended I/O System 
configuration file (EDEVCF.A86) must contain %DEV^INFO^BLOCK macro calls 
for each of these devices. The macro calls should assign the logical 
names to be the same as the device names. As released, EDEVCF.A86 
contains macro calls for these devices. Refer to Chapter 12 for further 
information0 

The Extended I/O System must create the Human Interface as an I/O job. 
Thus EJ 0 BCF.A 86 must contain an %IO_JOB macro call for the Human 
Interface. The default prefix for the Human Interface job is the logical 
name of the Human Interface’s terminal (TO). As released, EJOBCF.A86 
contains a macro call for the Human Interface job. 

When specifying the %JOB macro for the Extended I/O System, you must 
ensure that its memory pool is large enough to include the Human 
Interface. To do this, you can specify a value of OFFFFH for the 
pooljnax parameter (refer to Chapter 4 for more information about the 
%JOB macro). You should also specify a value of OFFFFH for the pool^niax 
parameter in the Human Interface’s %IO_JOB macro call. However, if you 
specify OFFFFH for the Extended I/O System and the Human Interface, it is 
recommended that you specify equal pool_min and pool_max values in all 
other %JOB and %IO_JOB calls to prevent these other jobs from borrowing 
memory. 
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CREATING HUMAN INTERFACE VOLUMES 


Before you can Initially use the Human Interface, you must create iRMX 86 
volumes that are properly formatted and contain the Human Interface 
commands. Intel supplies one such volume in the IRMX 86 release 
package. This volume is a preconfigured flexible diskette in iRMX 86 
format (with a granularity of 128 bytes) that contains the Human 
Interface commands. You can use this diskette if your iRMX 86 system 
contains a flexible diskette drive connected to either an ISBC 204 
controller or an iSBC 215/218 controller. 

If your iRMX 86 system does not contain a flexible diskette drive, you 
must use the Files Utility to create your first Human Interface volume. 
Use the Files Utility FORMAT command to format the iRMX 86 volume and the 
Files Utility UPCOPY command to copy the Human Interface commands from 
the Human Interface release diskette to the formatted iRMX 86 volume. 
Refer to the iRMX 86 INSTALLATION GUIDE for a description of the Files 
Utility. The names of the command files to be copied from the ISIS media 
Include the name of the command with the extension ”.R86". For example, 
the name of the filename of the DIR command on the release diskette is 
’’DIR.R86". 


CREATING HUMAN INTERFACE COMMANDS 


One of the primary functions of the Human Interface is to execute files 
of object code contained on secondary storage devices. It does this by 
loading the code into iRMX 86 memory and creating jobs for this code. 

The Human Interface is released with several such files which contain the 
Intel-supplied Human Interface commands. You can also create your own 
files of object code for the Human Interface to load as jobs. The 
procedure for creating your own commands depends on the kind of 
development system you use. 


USING A SERIES III DEVELOPMENT SYSTEM 

If you use a Series III development system to develop your commands, you 
can produce load-time locatable code (LTL), position Independent code 
(PIC), or absolute code. To create LTL or PIC commands, which the Human 
Interface can load anywhere in dynamic memory, perform the following 
steps: 

1. Compile your code using the PL/M-86 conq>iler or assemble it using 
the 8086/8087/8088 Macro Assembler. 

2. Use LINK86 to link your code together with the necessary 
libraries and create an LTL or PIC module. Enter the LINK86 
command as follows: 
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I 


RUN :fx:LINK86 & 

: fx: command *obj, & 

;fx:HPIFC.LIB, & 

:fx:LPIFC.LIB, & 

:fx:EPIFC.LIB, & 

:fx;IPIFC.LIB, & 

:fx:RPIFC.LIB & 

TO :fx: command & 

PRINT(:fx:command.mpl) STMBOLCOLUMNS(2) & 

OBJECTCONTROLS(PURGE) & 


PRINTCONTROLS(LINES, PUBLICS, NOCOMMENTS, SYMBOLS) & 
BIND SEGSIZE(STACK(stacksize)) MEMPOOL(minsize,maxslze) 

where : 

:fx: The appropriate disk Identifiers, Indicating the 

drives containing the modules. 


command. obj File containing the assembled or conq)iled object 
code for your command. You can link in several 
files or libraries at this point, if necessary. 


HPIFC.LIB 

LPIFC.LIB 

EPIFC.LIB 

IPIFC.LIB 

RPIFC.LIB 


Interface libraries for the Human Interface, 
Application Loader, Extended I/O System, Basic I/O 
System, and Nucleus. These libraries satisfy 
external references caused by making system calls. 


command File on which LINK86 places the linked command. 

After transferring this file to an IRMX 86 
secondary storage device, you can invoke the 
command by entering its pathname. 

command. mpl File on which LINK86 places the link map. 


stackslze Size, in bytes, of the stack needed by the 

command and any system calls that the command 
makes. The Human Interface uses this value when 
it creates a job for the command. 


mlnslze Minimum and maximum sizes of the command's dynamic 

maxsize memory requirements, in bytes. The Human 

Interface uses these values when it creates a job 
for the command. 


The code is now ready to be transferred to an IRMX 86 secondary 
storage device. You do not need to process the code further with 
L0C86. 

3. Use the Files Utility or the Human Interface UPCOPY command to 
copy the linked command from the development system disk to an 
IRlff 86 secondary storage device. At this point you can invoke 
the command by entering its pathname at the Human Interface 
terminal. 
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You can also create your commands as absolute object modules, if you 
wish* To do this, use the output file produced by LINK86 as input to 
L0C86, and use the ADDRESSES control to specify absolute addresses for 
the code* 

There are limitations to commands containing absolute code* The next 
section discusses these limitations further* 


USING A SERIES II DEVELOPMENT SYSTEM 

If you use a Series II development system to develop your commands, you 
can produce only absolute object code which the Human Interface must load 
into one particular area of memory* To create absolute commands, perform 
the following steps: 

1* Compile your code using the PL/M-86 compiler or assemble it using 
the 8086/8087/8088 Macro Assembler* 

2* Use LINK86 to link your code together with the necessary iRMX 86 
interface libraries* Enter the LINK86 command as follows: 


:fx:LINK86 & 

:f x:command*ob j, & 

:fx:HPIFC*LIB, & 

:fx:LPIFC*LIB, & 

:fx:EPIFC*LIB, & 

:fx:IPIFC*LIB, & 

:fx:RPIFC*LIB & 


TO :fx: command* Ink PRINT(:fx: command *mpl) 

where the parameters of this command mean the same as they do when 
entered with the Series III version of the LINK86 command* Notice 
that when using the Series II development system, you do not 
preface the LINK86 command with RUN and you do not use the 
SYMBOLCOLUMNS, OBJECTCONTROLS , PRINTCONTROLS, BIND, MEMPOOL, and 
SEGSIZE controls* These are not supported with the Series II 
version of LINK86* With the exception of BIND and MEMPOOL, you 
enter the omitted controls in the LOC86 command* 

3* Use L0C86 to assign absolute addresses to the linked module 
created by LINK86* Enter the L0C86 command as follows: 


:fx:L0C86 :fx: command* Ink TO :fx: command & 

ORDER (CLASSES (CODE, DATA, STACK, MEMORY)) & 

ADDRESSES (CLASSES (CODE (absolute_address) ) ) & 

SEGSIZE (STACK (stacksize)) & 

MAP PRINT (:fx:command*mp2) SYMB0LC0LUMNS(2) & 

OBJECTCONTROLS (PURGE) & 


PRINTCONTROLS (LINES, PUBLICS , NOCOMMENTS , SYMBOLS ) 


where: 

command* Ink Name of the link file produced previously by 

LINK86* 
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command Name of the file In which LOC86 writes the 

absolute module. After transferring this 
file to an iRMX 86 secondary storage device, 
you can invoke the command by entering its 
pathname. 


absolute^address Absolute starting location of the code 

segment of the command. L0C86 locates the 
remaining segments after the code segment. 
You must reserve these areas of iRMX 86 
memory during configuration with the %SAB 
macro (refer to Chapter 4). 

stacksize Size, in bytes, of the stack needed by the 

command and any system calls that the 
command makes. 


command. mp2 Name of the file in which LOC86 writes the 

locate map. 

4. Use the Files Utility or the Human Interface UPCOPY command to 
copy the located command from the development system disk to an 
IRMX 86 secondary storage device. If you have reserved the areas 
of iRMX 86 memory that the command needs with the %SAB macro 
during system configuration, you can invoke the command by 
entering its pathname at the Human Interface terminal. 


ADDITIONAL REQUIREMENTS FOR ABSOLUTE CODE 

When the commands you create contain absolute object code, you must take 
steps during the configuration process to ensure that this code loads and 
executes correctly, without affecting the remainder of the application 
system. 

Since absolute code contains the addresses at which it is to reside as 
part of the code, the Application Loader, when called by the Human 
Interface, cannot load this code at any convenient place in iRMX 86 
memory. Instead, it must load this code at the exact place specified in 
the code. If that place in iRMX 86 memory contains other objects (as it 
might if the memory is part of a dymanic memory pool), the act of loading 
the file can harm or destroy other tasks. If the place in memory 
contains part of the Operating System, the results can be worse. In 
order to ensure that no damage occurs when the Application Loader loads 
absolute files, you must use the %SAB macro call to reserve areas into 
which the Application Loader (when called by the Human Ingerface) will 
later load code (refer to Chapter 4 for a description of the %SAB 
macro). If you do this, no other objects will use the specified areas of 
memory, and the Application Loader can safely load your commands into 
that area for execution. 

If you create your commands as LTL or PIC modules on a Series III 
development system, you do not have to reserve memory with %SAB macros. 
The Application Loader loads LTL and PIC modules into convenient areas of 
dynamic memory. 
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One of the iRMX 86 release diskettes contains a demonstration system. 
This system consists of the following: 

• Nucleus 

• Debugger 

• root job 

• application job consisting of a BASIC interpreter 

The system contained on the release diskette has already been 
configured. In order to run it, make sure that your hardware is 
assembled correctly and load the system into your iSBC 86/12A single 
board computer. Refer to the iRMX 86 INSTALLATION GUIDE for further 
information on using this system. This appendix, however, shows how to 
use the procedures described previously in this manual and build the 
demonstration system from its individual parts. 

In order to build the demonstration system, this appendix assumes that 
you have the following: 

• An INTELLEC Series II Microcomputer Development System with at 
least four disk drives. 

• A system disk containing ASM86, LINK86, and LOC86. 

• The Nucleus release diskette, the Debugger release diskette, the 
demonstration system release diskette, and the iSBC 957A or 
iSBC 957 b release diskette. 


This appendix uses the SUBMIT files provided on the subsystem release 
diskettes and described in the previous chapters of this manual to link 
and locate the Nucleus and Debugger. The demonstration system release 
diskette contains different SUBMIT files that link and locate the 
Nucleus, Debugger, and TBASIC Interpreter. These SUBMIT files do not, 
however, follow the disk drive conventions outlined in Chapter 4. They 
assume that you have only two disk drives in your development system. 

You can use the files on the demonstration system release diskette, but 
this appendix does not describe the commands used to submit them. 

This Appendix also makes assumptions about terminal characteristics, 
naming files, and placing files on diskettes. These are made for 
convenience, not out of necessity. It also assumes that you are going to 
use the iSBC 957A/B package to load the system into the iSBC 86/12A 
single board computer. 



EXAMPLE SYSTEM CONFIGURATION 


PREPARE A MEMORY MAP 

The first step in the configuration process is preparing the memory map 
to describe the general layout of the system. Figure A-1 contains such a 
memory map. 

There are several things to notice about this memory map. They are: 

• The highest RAM address recorded indicates that this system has 
128K of RAM. 

• The iSBC 957A/B package will be used to load this system into 
memory. Thus space is allocated In the memory map for the 
iSBC 957A or ISBC 957B monitor. 

• The modules will be located in memory as described in Chapter 4. 
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iRMX" 86 SYSTEM MEMORY MAP WORKSHEET 

Configuration file name: 

Start address/ Module Length Absolute 

Data segment base Address 


FFFF:F 



(reserved) 



reset vector ^ 

^ FFFF : 0 


iSBC 957A/B monitor 

/ FE00:0 


Highest RAM address \ 

" ' 1FFF:F - 









EXAMPLE SYSTEM CONFIGURATION 


CONFIGURE THE SUBSYSTEMS AND LINK AND LOCATE THE SYSTEM 

The next steps you must perform Involve preparing configuration files for 
the Nucleus and the Debugger, assembling these files, and linking and 
locating all of the pieces of your system. You should fill out the 
memory map each time you locate a module, in order to keep track of the 
modules and the memory that they require. Figure A-2 shows a filled out 
memory map. The following sections refer to this figure. 
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iRMX’" 86 SYSTEM MEMORY MAP WORKSHEET 


Configuration file name:^ 

Start address/ 

Data segment base 


Module 


Length 


Absolute 

Address 




©( 




®{ 



(reserved) 

reset vector 


iSBC 957A/B monitor 


Highest RAM address 

SS=1135:0 


length=0A04 

Application Job 

CSTART=0DD0:90 





Root job 


- ....... .... ... -X 




. . ^ r ^ 

Debugger 


. - .... . ^ 




Nucleus 


Wake-up addresses 


Free space 


iSBC 957A/B monitor data 


Interrupt vector 

- - ... - — V 


< 

< 


< 

< 

< 

< 

< 


< 




< 


< 

< 


FFFF:F 

FFFF:0 
FE00:0 
IFFF : F 
llEAtO 
0E70;0 

0D70:0 

0D6E : 5 
611:0 

60F:1 

104:0 

100:0 

80:0 

40:0 

0:0 


Figure A-2. Completed Memory Map 









EXAMPLE SYSTEM CONFIGURATION 


PREPARE, LINK, AND LOCATE THE NUCLEUS 

You should start the configuration process with the Nucleus. To do this, 
place the diskettes in the proper drives of the development system 
(system diskette in drive FO, configuration diskette in drive Fl, Nucleus 
release diskette in drive F2, and scratch and listing diskette in drive 
F3). Then copy the Nucleus configuration file, NTABLE.A86, from the 
release diskette to your configuration diskette. Modify NTABLE.A86 so 
that it includes only those features and system calls that your 
application system requires. (You do not need to modify NDEVCF.A86 if 
you are running on the iSBC 86/12A board.) Figure A-3 shows a modified 
version of this file that specifies the system calls and features needed 
by the TBASIC interpreter. 


s include c;F2:ntablf:.»^acj 

SEJECI 


NUCLEUS FE»TUHE CONFIGUR AITOV TABLE 

TO LEAVE OUT A FEATURE, CHANGE THE 10 THE COMMENT 

character 

%FAHAmFIEH-VALTUATTUN 

%system.exceptiun_handlep 


SEJECI 


nucleus primitive conftguhaiton table 

TO configure a nucleus PRlMiTlVE OUT OF THE IRV/ 86 SYSTEM, 

replace TrtF BY XHe COMMENT CHAPACTER CALLS TO 

PHIMITTVES NOT CONFIGURED Tn THe SYSTeM WILL RESULT IN AN 

fsnut$cunfigured exceptional condition. 


ihogfitype 

IKOOISABLEDELETION 

fROENABLEDELETlON 

%ROCATALOGObJECl 

%ROUNCAr ALOGOBJECX 

%R0L00KUPQBJECT 

JROCPEATEEXTENSION 

;rouEuEteextension 

;ROCREATECOMPOSITE 


Figure A-3. Example Nucleus Configuration File 
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;RODFLETECnMPOSiTE 
?ROlNSPECTCQMpOSTTE 
; roaliercomfosite 
; ROFORCEnELETE 
tROCREATEJOB 
.•RODELETEJOb 

trooffspring 
%rocreatftask 
%rodelftetask 
%R0SUSPENDTASK ^ 
%ROREsnMETASK /t- 

*roslefp 

tROGEITASKTOKENS 

%rqgetprtority 

JKOSErPRIORlTY 

*ROCREATEMA1LBOX 

tRODELETEMAlLBOX 

%HOSENDmESSAGE 

%RORECEIVE«ESi>AGF 

%ROCREATESEMApHQRt 

%RODELErESFMAPHOPE 

AiROSEt^nUNITS 

tRORECElVElIhiTTS 

yROCREATEREGION 

yROOFLETEKEGIUN 

;rosEndcontkol 

yROKECEiVECONTROL 

;rqacceptcontrol 

%rocreatfsegmem 

%RQDELE1ESEGMENI 

%R0GFTSI7E 




yROGETPOOLATTRIB 

7ROSEIPOOLMIN 

?rqsfiosextension 

%R0SFTIN'^ERRUPT 

;R0ENTFRTNTERRUPT 

%R0£NABLE 

HRQOISABLE 

;roreset interrupt 

JROGFTLEVEL 

%ROEXlTiNTERRUPT 

tROSIGNAl.lNXFKRUPT 

%ro«»aitinterrupt 

yROGFlEXCEPlIONriANDLFR 
yROSETEXCEPTl unhandler 
%ROSIGNALEXCEPTIOn ^ 


End 


Figure A-3. Example Nucleus Configuration File (continued) 
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Next, copy the Nucleus SUBMIT file, NUCLUS.CSD from the release diskette 
on drive F2 to the configuration diskette on drve FI. Modify the ASM86 
command In NUCLUS.CSD so that It reads the configuration file 
(NTABLE.A86) from drive Fl Instead of from drive F2. Then call the 
version of NUCLUS.CSD that resides on Fl to assemble the configuration 
files and link and locate the Nucleus. From the memory map In Figure 
A-1, you can see that the Nucleus should be located at address 104:0. 

This allows room for the Interrupt vector and the ISBC 957A/B monitor at 
lower addresses. Therefore, enter the following command: 

SUBMIT :Fl:NUCLUS(date, 1040H) 

where date Is the date on which you submit the file. NUCLUS.CSD places 
the located Nucleus In file NUCLUS on drive Fl. It places the locate map 
In file NUCLUS. MP2 on drive F3. Figure A-4 shows the Important parts of 
the Nucleus locate map. 


ISiS-n «CS-b6 LnCAl’FK, VI. 3 1 rvOKFC : 


LOC86 i 

:f3:nucliis.inK lu ;fl:nuclus 
MAP PHI'<T( : t3;nucius.n.p^) *i 

NULlNfcf. K jCjMMFriT5 ^USYHulU-o A 
SfGST^,F(data(:<iJ ,stack(0) ) & 

ORDLP ( CLASSES (. code , da td J ) S 


ADDKF GSclSCCbAoStS (code ( 01 u40hj ) ) 

WARNING 2fa: URCPdA cil.MG SlZr, OK SKGn.ENT 

SEGMKM: STACK 

WARNING 2b: Dh CHtAST SIZF UF St-GN'KuT 

SEGMENT: DATA 

SYMBOL, TABl.L JF MjDuLE NDKGIN 
READ FROM FILE : F 1 : wUCI.oS . Li\K 
WRITTEN TO FILF :F1;NJCLU5 

BASE OFFSET TYPE olMH JL OFFSET TYPE SYMBOL 

0104H OOOOH PUH sibEGltJ 

MEMORY MAP UF MOOuLE jPtGlN 
READ F ROM F ILE : F3 : :j IJCLUS . LUK 
WRITTEN TO FILE :Fl:NuCL(iS 


SEGMENT MAP 


START STOP LENGTH ALIGN NAME CLASS 

OOOOOH 003FFH O 4 OOH A (ABSOLUTE) 

01040H 05FEDH 4FAEH W CODE CODE 

05FEEF1 O0OO7H OOIAH W ObJ-SEG CODE 

06008H 06011H OOOAri W JOB.SEG CODE 

06012H 06025H 0014H ' W TASK.SEG CODE 


' rb] sLSl Figure A-4. Nucleus Locate Map 

; PS'. P, L.5T 

\ ' li , 1. 



EXAMPLE SYSTEM C0NFI6UBATI0N 


06026H 

0602DH 

OOObH In 

Mfa.SEG 

CODE 

0602eH 

06035H 

0008H W 

SEM_SEG 

CODE 

06036H 

0603FH 

OOOAH W 

REG-SEG 

CODE 

06040H 

0604DH 

OOOEH W 

FS_SEG 

CODE 

0604EH 

06067H 

OOIAH W 

INT_SEG 

CODE 

06068H 

0606DH 

0006H W 

EXCEP-SEG 

CODE 

0606EH 

0609DH 

0030H W 

VALID-SEG 

CODE 

0609EH 

060A2H 

0005H W 

P1C_CNF«SEG 

CODE 

060A4H 

060B5H 

0012H W 

-IMH»PORT 

CODE 

060B6H 

060C7H 

0012H W 

-EOI.PORT 

CODE 

060C8H 

060D9H 

0012H W 

-ISR«READ_PORT 

CODE 

0600AH 

060E2H 

0009H B 

-PIC-INFO 

CODE 

060E3H 

060ECH 

OOOAH B 

TIMER-CNF-SEG 

CODE 

060EEH 

060EEH 

OOOOH W 

CSEG 

CODE 

060EEH 

060EFH 

0002H W 

SLAVE-SEG 

CODE 

060FOH 

060F0H 

OOOOH G 

SySTEM_DATA_St 

DATA 




-G-ID 


060F0H 

060F1H 

0002H W 

DATA 

DATA 

06100H 

06100H 

OOOOH G 

??SEG 


06100H 

06100H 

OOOOH G 

LlB-87-PUb 


06100H 

06100H 

OOOOH W 

STACK 

STACK 

06100H 

06100H 

OOOOH W 

MEMORY 

MEMORY — (A^ 

GROUP MAP 




ADDRESS GROUP OR SEGMENT NAME 



060F0H 

DGKOUP 





SYSTEM_DATA-SEG-ID 




DATA 




01040H 

CGROUP 





CODE 





OBJ-SEG 





JOB-SEG 





TASK.SEG 

• 

• 

• 





Figure A- 

*4. Nucleus Locate Map (continued) 

As you can see from arrow A1 In Figure 

A-4, the next available memory 

location 

Is 610:0* The 

last location used by the Nucleus 

was 60F:1. 1 

Allowing for additional 

space, record 

these values on the 

memory map as | 

shown in 

portions A and 

part of B in Figure A-2. 
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EXAMPLE SYSTEM CONFIGURATION 


PREPARE, LINK, AND LOCATE THE DEBUGGER 

You should continue the configuration process with the Debugger* This 
example assumes that you can use the released versions of the Debugger 
SUBMIT file and configuration file* Thus you do not need to copy any 
files to your configuration diskette and make modifications* Just make 
sure that you place the diskettes In the proper drives of your 
development system (system diskette In drive FO, configuration diskette 
In drive FI, Debugger release diskette In drive F2, and scratch and 
listing diskette In drive F3)* Then call the Debugger SUBMIT file, 
DB.CSD, to assemble the DTHCNF*A86 and link and locate the Debugger* 
Since you have already located the Nucleus, you can use the figure of 
6110H In the call to DB.CSD* This call appears as follows: 

SUBMIT :F2:DB(date, 6110H) 

where date Is the date on which you submit the file* DB.CSD places the 
located Debugger In file DB on drive Fl* It places the locate map In 
file DB.MP2 on drive F3. Figure A-5 shows the Important parts of this 
locate suip* 


ISIS-II WCS-86 LO'CATER, VI. 3 INVOKED Bl: 


LOC86 & 

:£3:db*lnK TO :fl:db a 

MAP PRINT! :f3:dD*mp2) & 

NOLINES NOCOMMENTS NOSYMBOLS & 

SEGSIZE(StacK(0) ) & 

OKDER(classes(code, data)) & 


ADDRESSES(Ciasses(C0de(61 lOH) ) ) 

WARNING 2b: DECREASING SIZE OF SEGMENT 

SEGMENT: STACK 

SYMBOL TABLE OF MODULE DBUGA 
READ FROM FILE :F3:0B.LNK 
WRITTEN TO FILE :F1:DB 

BASE OFFSET TYPE SYMBOL BASE OFFSET TYPE SYMBOL 

0611H OOOOH PUB RODbUGINIT 

MEMORY MAP OF MODULE DBUGA 
READ FROM FILE :F3:DB.LNK 


WRITTEN 

TO FILE 

:F1 :DB 




SEGMENT 

MAP 





START 

STOP 

LENGTH 

ALIGN 

NAME 

CLASS 

06110H 

0D1F3H 

70E4H 

W 

CODE 

CODE 

0D1F4H 

0D1F9H 

0006H 

B 

TH.CNF-SEGl 

CODE 


Figure A-5* Debugger Locate Map 
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EXAMPLE SYSTEM CONFIGURATION 


ODIFAH 

ODIFFH 

0006H 

B 

TH_CNF«SEG2 

CODE 

00200H 

0D207H 

0008H 

B 

TH_CNF_SEG3 

CODE 

0D208H 

0D20BH 

0004H 

B 

TH_CNF_SEG4 

CODE 

0D20CH 

0D20DH 

0002H 

B 

TH«CNf »SEG5 

CODE 

0D20EH 

0D216H 

OOOBH 

B 

N0RW«1N-MBX_SE 

CODE 

0D219H 

0D224H 

OOOCH 

B 

•* VJ 

N0RM_0UT-MBX_S 

-EG 

CODE 

00226H 

0D6E5H 

04C0H 

W 

DATA 

DATA 

006F0H 

0D6F0H 

OOOOH 

G 

??SEG 


0U6F0H 

0D6F0H 

OOOOH 

W 

STACK 

STACK 

0D6F0H 

0D6F0H 

OOOOH 

M 

MEMORY 

MEMORY 


GROUP MAP 

ADDRESS 

GROUP OR SEGMENT NAME 

0D220H 

DGROUP 

DATA 

06110H 

CGROUP 

CODE 

TH_CNF.SEG1 

TH_CNF_S£G2 

TH_CNF«SEG3 

TH»CNF_SEG4 

IH«CNF_SEG5 

NOHM.IN.MBX-SEG 

N0RM.OUT_MBX.SEG 


Figure A«-5. Debugger Locate Map (continued) 


Arrow B1 shows the only Important piece of Information in Figure A-5 that 
you should record on the memory map« It identifies the next available 
memory location, address 0D6F:0. The last location used by the Debugger 
is 0D6E:5. Record address 0D6E:5 on the memory map* This is shown in 
portion B of Figure A-2* You need to know the next available address in 
order to leave enough space for the root job and correctly locate the 
application job* 

The entry point of the Debugger is determined from the address at which 
you locate the Debugger* The base portion of the entry point is the base 
portion of the location address (611)* The offset portion of the entry 
point is 0. Thus the Debugger entrv point is 611:0* You must supply 
this address later in the ZJOB macro call for the Debugger* 




EXAMPLE SYSTEM CONFIGURATION 


ALLOW SPACE FOR THE ROOT JOB 

Use the address 0070:0 as the starting address of the root job. Record 
this value and the estimated size on the memory map. You do not know the 
exact size since you have not created the root job yet. However, for this 
system, use a size estimate of 600H bytes. Add this value to the starting 
address and record the result, 0DD0:0, on the memory map. Use this value 
as the starting address of the application job. Portion C of Figure A-2 
shows this. 


LINK THE APPLICATION JOB 


Next, use LINK86 to link the modules of the TBASIC Interpreter job 
together. Before you do this, however, copy the file APXIOL.LIB from the 
iSBC 957B release diskette (of SBCIOL.LIB from the iSBC 957A release 
diskette) to your configuration diskette. Also copy the interface library, 
RPIFL.LIB, from the Nucleus release diskette to your configuration 
diskette. Place the diskettes in the proper drives of the development 
system (system diskette in drive FO, configuration diskette in drive Fl, 
demonstration system release diskette in drive F2, and scratch and listing 
diskette in drive F3), and enter the following command: 


LINK86 :F2: TBASIC. OBJ, & 

;F2;PTHI0.0BJ, & 

:F2:PT0KEN.0BJ, & 

;F2;PERR.0BJ, & 

:F2:PINT.LIB, & 

;F1:APXI0L.LIB, & 

:F1:RPIFL,LIB & 


TO ; F3: TBASIC. LNK MAP PRINT( :F3: TBASIC. MPl) 


The files linked in this process contain the following information: 

TBASIC. OBJ This file contains the initialization task and the 

interpreter. 

PERR.OBJ This file contains error printing routines. 

PTOKEN.OBJ This file contains a token scanner for PL/M-86 

routines . 

PTHIO.OBJ This file contains the interface between the Terminal 

Handler and the interpreter. 

PINT. LIB This file contains a library of PL/M-86 routines that 

interface with the iRMX 86 Operating System. 

APXIOL.LIB This file contains the iSBC 957B library. 

BUPIFL.LIB This file contains the interface library for 

application jobs. 


LINK86 places the linked application job in file TBASIC. LNK on drive F3. 


A-12 



EXAMPLE SYSTEM CONFIGDRATION 


LOCATE THE APPLICATION JOB 


After linking the application job, use L0C86 to assign absolute 
locations* By examining the memory map, you can see that the next 
available location Is ODDO:0. Use LOC86 to locate the application Job | 

there* To do this, enter the following command: 

LOC86 ;F3:TBASIC*LNK TO :F1:TBASIC 

ORDER (CLASSES (CODE, DATA, STACK, MEMORY)) 

ADDRESSES (CLASSES (CODE (ODDOOH))) 

MAP PRINT (:F3;TBASIC*MP2) 

OBJECTCONTROLS(NOLINES , NOCOMMENTS , 

NOPUBLICS , NOSYMBOLS) 

LOC86 places the located application Job in file TBASIC on drive Fl. It 
places the locate map in file TBASIC*HP2 on drive F3* Figure A-6 shows 
the loportant portions of the application Job locate map* 



ISIS-II MC5-B0 UUCATER, VI. 3 INVOKED BY: 

L0C86 :F3:TBASIC*LNK TO :F1:TBASIC & 

ORDER (CLASSES (CODE, DATA, STACK, MEMORY)) S. 
ADDRESSES (CLASSES (CODE (ODDOOH))) 6 

MAP PRINT ( ;F3:TBASIC.MP2) & 

ObJECTCONTROLS(NOLINES,NOCOMMENTS, & 

NOSYMBOLS, NOPUBLICS) 


SYMBOL TABLE OF MODULE TBASIC 
READ FROM FILE : F i : TB AS 1C . LNK 
WRITTEN TO FILE :F1:TSASIC 


BASE 

OFFSET 

TYPE 

SYMBOL 

BASE 

OFFSET 

TYPE 

SYMBOL 

ODDOH 

OOCEH 

PUB 

WSTART 

ODDOH 

0090H 

PUB 

CSTART 

0FF8H 

0095H 

PUB 

TXTBGN 

0FF8H 

1095H 

PUB 

TXTEND ^ 

0FF6H 

OOOEH 

PUB 

VARBGN 

0FF3H 

005BH 

PUB 

rXTUNF 

0E81H 

OlECH 

PUB 

getchar 

0E81H 

018FH 

PUB 

FLUSHINPUT 

0E81H 

013FH 

PUB 

PUTCHAR 

0E81H 

OOEAH 

PUB 

FLUSHOUTPUT 

0E81H 

OOIAH 

PUB 

initthio 

0EA4H 

0043H 

PUB 

TOKENIZE 

0EA4H 

0022H 

PUB 

HEX 

0EA4H 

OOOAH 

PUB 

HEXCHARS 

0EE7H 

0054H 

PUB 

PERROR 

OEFOH 

OOOAH 

PUB 

PCRTSEHA 

0EF9H 

OOOCH 

PUB 

pdelsema 

OFOIH 

OOlOH 

PUB 

PSNDUNIT 

OFOAH 

OOOAH 

PUB 

prcvunit 

0F13H 

OOOCH 

PUB 

PCRTMBOX 

OFICH 

0004H 

PUB 

pdelmbox 

0F24H 

0008H 

PUB 

PSENOMSG 

0F2DH 

0006H 

PUB 

PRECVMSG 

0F36H 

OOOAH 

PUB 

PCRTSEGM 

0F3EH 

0012H 

PUB 

PDELSEGM 

0F47H 

OOOAH 

PUB 

PCRTTASK 

0F51H 

OOOCH 

PUB 

PDELTASK 

0F59H 

OOOEH 

PUB 

PSUSTASK 


Figure A*~6. Application Job Locate Map 



EXAMPLE SYSTEM CONFIGURATION 


HEMORI MAP OF MODULE TBASIC 
READ FROM FILE I F3 ; TbAS IC. LNK 
WRITTEN TO FILE :Fi:TBASIC 

MODULE START ADDRESS PARAGRAPH = ODDOH OFFSET = 0090H 
SEGMENT MAP 


START 

STOP 

LENGTH 

ALIGN 

NAME 

CLASS 

ODDOOH 

0E80EH 

OBOFH 

G 

CODE 

CODE 

0E810H 

0EA49H 

023AH 


TEHMINALHANDLE 

-RIO.CODE 

CODE 

0EA4AH 

0EE71H 

0428H 


TOKENIZE-.CODE 

CODE 

0EE72H 

0EF02H 

0091H 


PERROR-CODE 

CODE 


11342H 

11342H 

OOOOH 

w 

INITTASKSIGNAL 

--DATA 

DATA 

11350H 

11D53H 

0A04H 

G 

STACK 

STACK 

11D60H 

11D60H 

OOOOH 

G 

??SEG 


11D60H 

11E9EH 

013FH 

W 

CONST 

CONST 

llEAOH 

UEAOH 

OOOOH 


MEMORY 

MEMORl 



GROUP MAP 

ADDRESS GROUP OR SEGMENT NAME 
0FF30H DGROUF 
CONST 
DATA 
DATA2 
STACK 
MEMORY 
ODDOOH CGROUP 
CODE 


Figure A-6. Application Job Locate Map (continued) 


As with the Debugger locate map, there are three pieces of In^ortant 
Information In Figure A-6 which you must record on the memory map. 
Arrows Dl, D2, and D3 mark them* 

Arrow D1 shows the next available memory location, llEAsO. Record this 
value on the memory map* It will be used when when calling the ZSAB 
macro to reserve memory for the application system* This Is shown in 
portion D of Figure A-2* 
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EXAJylPLE SYSTEM CONFIGURATION 


Arrow D2 shows the entry point of the first-level job^s initialization 

task, CSTART# Record the address of CSTART, 0DD0:090, on the left | 

portion of the memory map, near the other information for the application 

job* This is shown in portion D of Figure A-2* You must later provide 

this information in the %JOB macro call for the application job* 

Arrow D3 shows the stack segment starting address and length* Record the 
starting address, 1135:0, and the length, 0A04, on the left portion of | 

the memory map, near the other information for the application job* This 
is shown in portion D of Figure A-2. This job has a statically allocated 
stack and so you must provide this information in the %J0B macro call. 

This application job assumes that the code segment and the data segment 
are the same* Therefore, it is not necessary to record any information 
about the data segment in the memory map* 


BUILD THE CONFIGURATION FILE 


After you have located the- Nucleus, the Debugger, and the application job 
and filled out the memory map, you have enough information to build the 
configuration file needed by the root job. This involves creating a file 
containing an $INCLUDE statement, a %SYSTEM macro call, %SAB macro calls 
and %J0B macro calls* The following sections show filled out worksheets 
for these macros and discuss the parameters* Then the actual 
configuration file itself is shown* 


%J0B MACRO CALLS 

For this system, you must make two %J0B calls; one for the Debugger and 
one for the application job* The order in which you include these calls 
in the configuration file is important because that is the order in which 
the jobs are initialized when the system starts running* Make the %J0B 
call for the Debugger first* 


Debugger %J0B Call 

Figure A-7 shows the completed worksheet for the Debugger's %J0B call* 
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EXAMPLE SYSTEM CONFIGURATION 


Macro call: JOB (defines first-level jobs ) - for Debugger 

Number of calls required one for each first-level job 

CONFIGURATION FILE NAME: CONFIG. A86 


FORMAT: 



suggested 



parameter 

iZEe 

default 

value 

%JOB 

(directory's ize. 

word 

(0) 

0 


pool min. 

word 


IFFH 


pool max, 

word 

y VA. A A A AL y 

IFFH 


max objects, 

word 


OFFFFH 


max tasks. 

word 


OFFFFH 


max jobjriority 

byte 


0 


exception handler entry. 

addr 

(0:0) 

0:0 


exception handler mode. 

byte 

(1) 

1 


job_f lags. 

word 

(0) 

1 


ini t_task_prior i ty , 

byte 

(0) 

0 


inltjtaskjantry. 

addr 


611:0000 


data_segment_base , 

base 

(0) 

0 


s tackjpolnter , 

addr 

(0:0) 

0:0 


stack_slze. 

word 

(512) 

512 


task^f lags) 

word 

(0) 

0 

NOTES: 





1. 

Type addr Is specified as 

base: offset 


i 

2. 

Types addr and base must 

be entered as 

hexadecimal numbers 


without the suffix H. Types word and byte default to 
decimal, but will accept all radix suffixes. 


Figure A— 7. Completed Debugger %JOB Macro Worksheet 
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EXAMPLE SYSTEM CONFIGURATION 


The parameters are described in the following: 


directory^size 

through 

max^tasks 

max_job_priority 


exception_handler_- 

entry 


The first five parameters affect the Debugger 
while it is running. Enter these parameters 
as shown in Figure A-7. 

The 0 indicates that the priority of the root 
job is the maximum priority for tasks in this 
job. 

The 0:0 value means that the default system 
exception handler identified in the %SYSTEM 
call is used. 


exception_handler_mode The 1 indicates that the exception handler is 

called in the event of programming errors. 


job flags 


init_task_priority 

init_task_entry 


The 0 indicates that the Nucleus does not 
validate parameters. 

This value was listed in Table 4-1. 

This value depends on the address specified 
when locating the Debugger. It is always 
(base of the location address) :0. 


data segment base 


The 0 Indicates that the Debugger assigns its 
own data segment. 


stack_^pointer 


The 0:0 indicates that the Nucleus allocates 
the stack segment. 


stack size 


This value was listed in Table 4-1. 


task_f lags 


The 0 indicates that the Debugger does not 
use the 8087 NDP component. 


Application Job %J0B Call 

Figure A-8 shows the completed %J0B macro worksheet for the application 
job. 
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EXAMPLE SYSTEM CONFIGURATION 



Figure A-8. Completed Application Job %JOB Macro Worksheet 
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EXAMPLE SYSTEM CONFIGURATION 


The values shown in Figure A-8 are very similar to those shown in Figure 
A-7. The major differences are outlined as follows: 

lnit_task_j>riority A value of 131 is the recommended value for 

this job. 

init_task_entry This value was taken from the memory map. 

data_segment_base This 0 indicates that the task assigns the data 

segment. 

stack_j>ointer This job has a statically allocated stack. 

This value was taken from the memory map. 

stack size This value was taken from the memory map. 


%SAB MACRO CALLS 

This system uses two %SAB calls, one for the memory needed by the Nucleus 
and the first-level jobs, and the other for the remainder of the address 
space over 128K. Figure A^9 contains the completed worksheet for the two 
%SAB calls. 
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EXAMPLE SYSTEM CONFIGURATION 


I 


Macro call: SAB (for system address blocks) 

Number of calls required: one or more 

CONFIGURATION FILE NAME: 


FORMAT; 


parameter 


tZ££ 


suggested 
default value 


%SAB (start_base, 
end_base, 
type) 


base 

base 

see note 
1 


0 

llEA 

U U 


%SAB (start_base, 
end_base, 
type) 


base 2000 

base FFFF 

see note U U 

1 


%SAB 


(start_base, 

end_base, 

type) 


base 

base 

see note 
1 


U 


NOTES : 

1* The type parameter is reserved for future use. Enter the 
character U for this parameter. 

2. A SAB is declared between start_base:0 and end_base:F, 
inclusive. 

3* Types addr and base must be entered as hexadecimal numbers 
without the suffix H* Types word and byte default to decimal 
but will accept all radix suffixes. 


Figure A-9. Completed %SAB Macro Worksheet 
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EXAMPLE SYSTEM CONFIGURATION 


The first %SAB call shown In Figure A-9 reserves the memory needed for 
the entire application system* The end_base parameter Is taken from the 
memory map* It Includes the estimate for the root job* 

The second %SAB call shown In Figure A-9 reserves memory that Is not 
actually In the system* This system has only 128K bytes of memory* Thus 
addresses 2000:0 to 0FFFF:F are not used* Reserving these locations 
speeds the system Initialization process* 


XSYSTEM MACRO CALL 

Figure A-10 shows the completed worksheet for the XSYSTEM call* You must 
place this call last In the configuration file* 
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EXAMPLE SYSTEM CONFIGURATION 


Macro call: SYSTEM (system parameters) 

Number of calls required: exactly one 

CONFIGURATION FILE NAME: CONFIG. A86 


FORMAT: 

parameter 

tZ£e 

suggested 

default 

value 

%SYSTEM 

(nucleus^entry. 

base 


104 


rod_size. 

word 

(0) 

20 


mi n^t rans^s Iz e , 

word 

(64) 

64 


debugger. 

see note 

(A^ 

\ — jf 

A 


d e f aul t_e_h jp r o vi de d , 

1 

see note 

(N) 

D 


mode) 

2 

word 


1 


NOTES: 


1. Valid entries for the debugger parameter include: 

A Debugger available 
N No Debugger available 

2. Valid entries for the default_e_h_provided parameter Include: 

Y Yes 
D Debugger 
N No 

3. Types addr and base must be entered as hexadecimal numbers 
without the suffix H. Types word and byte default to 
decimal, but will accept all radix suffixes. 


Figure A-10. Completed %SYSTEM Macro Worksheet 
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EXAMPLE SYSTEM CONFIGURATION 


The parameters are described in the following: 


nucleus entry 


This value is taken from the memory map. 


rod_size 

and 

min trans size 


These values affect the system at run time. Use 
the values listed in Figure A-10. 


debugger The A indicates that the Debugger is available. 

default_e_h_provided The D indicates that the Debugger is used for 

the default exception handler. 

mode The 1 indicates that the Operating System 

transfers control to the exception handler (the 
Debugger) in the event of a programming error 
condition. 


CREATE THE ACTUAL CONFIGURATION FILE 

After you have filled out the macro worksheets, you can create the 
configuration file. To do this, create a file called CONFIG. A86 on your 
configuration diskette, and copy the information from the worksheets into 
it as well as an $INCLUDE statement for file CTABLE.MAC and an END 
statement. The statements in this file appear as follows: 

$INCLUDE (:F2; CTABLE.MAC) 

%SAB (0, llEA, U) 

%SAB (2000, FFFF, U) 

%JOB(0,1FFH,1FFH,OFFFH,OFFFFH, 0,0:0, 1,1, 0,611:0000,0,0:0, 512,0) 
%JOB(20, IFFH, OFFFFH, OFFFFH, OFFFFH, 0, 0:0, 1,1, 131, 0DD0:090, 0,1135:0, 
0A04H,0) 

%SYSTEM (104, 20, 64, A, D, 1) 

END 


GENERATE THE ROOT JOB 


You can now use the CROOT.CSD SUBMIT file to assemble the configuration 
file, link the root job, and locate the root job. Place the diskettes in 
the proper drives of your development system (system diskette in drive 
FO, conlguratlon diskette in drive Fl, Nucleus release diskette in drive 
F2, scratch and listing diskette in drive F3), and enter the following 
command : 

SUBMIT :F2:CR00T( CONFIG, date, 0D700H) 

Where date can be in any form, as long as it does not exceed nine 
characters. 
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EXAMPLE SYSTEM CONFIGURATION 


This command assembles the configuration flle» links It to the root job, 
and locates the root job at the correct address* L0C86 places the 
located root job In file CONFIG on drive Fl. It also places the locate 
map for the root job in file CONFIG. MP2 on drive F3. You can use the 
locate map to determine the actual size of the root job. When you 
configure your ROM/RAM system, you can update the memory map to reflect 
this value. 


LOAD THE SYSTEM 


At this point you can use either the ICE-86 In-circuit emulator or the 
I ISBC 957A/B package to load the system into memory. When you do, load 
the following files. In order, from your configuration diskette: 

NUCLUS 

I OB 

TBASIC 

CONFIG 
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APPENDIX B. BURNING THE NUCLEUS INTO 2732 PROM 


If you use the Universal PROM Mapper (UPM) version 3.2 to burn code into 
PROM, you cannot load the entire Nucleus with a single UPM READ command. 
In order to burn the Nucleus (and possibly some of your other programs), 
you must burn 16K byte pieces of the code into PROM. This appendix 
describes the procedures required to do this. It also lists the required 
hardware and software. Although this appendix refers specifically to the 
Nucleus, you can use the procedures described here to burn any large 
module into PROM. 


REQUIREMENTS 

In order to use the procedure outlined in this appendix, you must have 
the following hardware and software. 

• A linked Nucleus (NUCLUS.LNK) 

• LOGS 6 software 

• A UPP universal PROM Programmer with a 2732 personality module 

• 8 erased 2732A PROM modules 


With this hardware and software you can use the procedures in the 
following sections to place the Nucleus code into PROM. 


LOCATE THE NUCLEUS 

Use L0C86 to locate the Nucleus for a ROM/RAM configuration. Use a 
command similar to the following: 

LOC86 NUCLUS.LNK TO ROMNUC 

ORDER (CLASSES (DATA, STACK, MEMORY)) 

SEGSIZE (DATA(2), STACK (0)) 

ADDRESSES (CLASSES (CODE (rom_address) , 

(DATA (ram _address))) 

MAP PRINT (map_file) 

0BJECTC0NTR0LS(N0LINES , NOCOMMENTS , 

NOPUBLICS , NOSYMBOLS ) 

Chapter 5 describes the parameters of this command in detail. However, 
for the discussion in this appendix, the important parameter is 
rom_address. This parameter specifies the address in ROM where the 
Nucleus will reside. 


& 

& 

& 

& 

& 
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Also examine the locate map to determine the exact size of the code 
class* You need this information to determine the number of pieces to 
burn. 


BURN THE CODE INTO PROM 


To burn the code into PROM, Insert the 2732 personality module into the 
appropriate program socket (this appendix assumes socket 2). Then enter 
the commands shovm in Figure B-1. These commands are structured so that 
you can place them in a SUBMIT file. Tlie CNTL/E (control/E) characters 
in the figure return control to you so that you can insert a PROM into 
the UPP. After doing this, enter another CNTL/E to return control to the 
SUBMIT file. Make sure to place a new PROM into the UPP before each 
PROGRAM statement. 


UPM 

2732 

SOCKET- 2 

READ OBJECT FILE ;F2:R0MNUC FROM 0 TO 3FFFH START 0E8000H 
STRIP LOW FROM 0 TO 3FFFH INTO 4000H 
STRIP HI FROM 0 TO 3FFFH INTO 6000H 
CNTL/E PROGRAM FROM 4000H TO 4FFFH START 0 

CNTL/E PROGRAM FROM 6000H TO 6FFFH START 0 

CNTL/E PROGRAM FROM 5000H TO 5FFFH START 0 

CNTL/E PROGRAM FROM 7000H TO 7FFFH START 0 

READ OBJECT FILE :F2;R0MNUC FROM 0 TO 2AF9H START OECOOOH 
STRIP LOW FROM 0 TO 2AF9H INTO 4000H 
STRIP HI FROM 0 TO 2AF9H INTO 6000H 
CNTL/E PROGRAM FROM 4000H TO 4FFFH START 0 

CNTL/E PROGRAM FROM 6000H TO 6FFFH START 0 

CNTL/E PROGRAM FROM 5000H TO 557DH START 0 

CNTL/E PROGRAM FROM 7000H TO 757DH START 0 

EXIT 


Figure B-1 


UPM SUBMIT File to Burn the Nucleus into PROM 




BURNING THE NUCLEUS INTO 2732 PROM 


The commands in Figure B-1 assume that the Nucleus code class ranges from 
0E8000H to 0EEAF;9. You must modify the SUBMIT file to specify the 
correct addresses for your system. To give you a better understanding of 
how to do this, the individual UFM commands used to burn the first 
portion of the Nucleus are listed and discussed in detail. 


READ OBJECT FILE :F2:R0MNUC FROM 0 TO 3FFFH START 0E8000H 

This command reads the first piece of the object file from disk into 
a 16K INTELLEC memory buffer. The logical addresses of the memory 
buffer are 0 through 3FFFH. The absolute address of the module is 
specified as 0E8000H. 


STRIP LOW FROM 0 TO 3FFFH INTO 4000H 

This command separates the even address (low order) bytes from the 
file and copies them into another memory buffer. 

STRIP HI FROM 0 TO 3FFFH INTO 6000H 

This command separates the odd address (high order) bytes from the 
file and copies them into another memory buffer. 


CNTL/E PROGRAM FROM 4000H TO 4FFFH START 0 

This command burns the first half of the low order bytes into PROM. 
Make sure that you Insert a 2732 PROM into the UPP before entering 
this command. Include the CNTL/E character only if you use a SUBMIT 
file. This character returns control to you so that you can insert 
the PROM. After you do, enter another CNTL/E and processing resumes. 


CNTL/E PROGRAM FROM 6000H TO 6FFFH START 0 

This command burns the first half of the high order bytes into PROM. 


CNTL/E PROGRAM FROM 5000H TO 5FFFH START 0 

This command burns the second half of the low order bytes into PRCM. 
CNTL/E PROGRAM FROM 7000H TO 7FFFH START 0 

This command burns the second half of the high order bytes into PROM. 
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The remainder of the commands in Figure B-1 function similarly* For 
further Information about UIM, refer to the UNIVERSAL PROM PROGRAMMER 
USER'S MANUAL. 

After you have burned all the PROMs, plug them Into the memory board and 
test the system. 
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APPENDIX C. SYSTEM CALL USAGE 


This appendix lists the system calls used by fully-configured versions of 
the optional subsystems. This Information Is Important when you decide 
which system calls to Include In your final application system. Table 
C-1 lists the system calls used by the Terminal Handler, Table C-2 lists 
those used by the Debugger, Table C-3 lists those used by the I/O System, 
Table C-4 lists those used by the Extended I/O System, Table C-5 lists 
those used by the Application Loader, and Table C-6 lists those used by 
the Human Interface. 


Table C-1. System Calls Used by the Terminal Handler 


NUCLEUS 

SYSTEM CALLS 

CATALOG$OBJECT 

GET$SIZE 

CREATE$MAILBOX 

GET$TASK$TOKENS 

CREATE$SEGMENT 

GET$TYPE 

CREATE$TASK 

RECEIVE$MESSAGE 

DELETE$SEGMENT 

SEND$MESSAGE 

DISABLE 

SET$INTERRUPT 

ENABLE 

SIGNAL$INTERRUPT 

END$INIT$TASK 

EXIT$INTERRUPT 

WAIT$INTERRUPT 
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Table C-2. System Calls Used by the Debugger 


NUCLEUS 

SYSTEM CALLS 

CATALOG$OBJECT 

GET$SIZE 

CREATE$JOB 

GET$TASK$TOKENS 

CREATE$MAILBOX 

GET$TYPE 

CREATE$SEGMENT 

LOOKUP$OBJECT 

CREATE$TASK 

RECEIVE$MESSAGE 

DELETE$SE01ENT 

RESUME$TASK 

DISABLE 

SEND$MESSAGE 

DISABLE $DELETION 

SET$INTERRUPT 

ENABLE 

SET$PRIORITY 

ENABLE $DELETION 

SIGNAL$INTERRUPT 

END$INIT$TASK 

SLEEP 

EXIT$INTERRUPT 

SUSPEND$TASK 

GET$PRIORITY 

WAIT$ INTERRUPT 


Table C-3. System Calls Used by the I/O System 


NUCLEUS SYSTEM CALLS 

CATALOG$OBJECT 

DISABLE$DELETION 

SEND$CONTROL 

CREATE$COMPOSITE 

ENABLE$DELETION 

SEND$MESSAGE 

CREATE$EXTENSION 

END$INIT$TASK 

SET$INTERRUPT 

CREATE$MAILBOX 

FORCE$DELETE 

SET$OS$EXTENSION 

CREATE $REGION 

GET$LEVEL 

SIGNAL$EXCEPTION 

CREATE$SE(MENT 

GET$TASK$TOKENS 

SIGNAL$INTERRUPT 

CREATE $TASK 

GET$TYPE 

SLEEP 

DELETE$COMPOSITE 

LOOKUP$OBJECT 

UNCATALOG$OBJECT 

DELETE$MAILBOX 

RECEIVE$CONTROL 

WAIT$INTERRUPT 

DELETE$REGION 

RECEIVE$MESSAGE 


DELETE$SE(MENT 

RESET$INTERRUPT 


DELETE$TASK 

RESUME$TASK 
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Table C-4. System Calls Used By the Extended I/O System 


NUCLEUS SYSTEM CALLS 

BASIC I/O SYSTEM CALLS 

CATALOG$OBJECT 

DELETE$MAILBOX 

A$ATTACH$FILE 

CREATE$COMPOSITE 

DELETE$SEGMENT 

A$CHANGE$ACCESS 

CRETE$EXTENSION 

GET$TASK$TOKENS 

A$CLOSE 

CREATE$JOB 

GET$TYPE 

A$CREATE$DIRECTORY 

CREATE$MAILBOX 

LOOKUP$OBJECT 

A$CREATE$FILE 

CREATE$REGION 

RECEIVE$CONTROL 

A$DELETE$CONNECTION 

CREATE$SEGMENT 

RECEIVE$MESSAGE 

A$DELETE$FILE 

CREATE $TASK 

SEND$CONTROL 

A$GET$CONNECTION$STATUS 

DELETE$COMPOSITE 

SEND$MESSAGE 

A$GET$FILE$ STATUS 

DELETE$JOB 

SET$OS$EXTENSION 

A$OPEN 


UNCATALOG$OBJECT 

A$PHYSICAL$ATTACH$DEVICE 

A$PHYSICAL$DETACH$DEVICE 

A$READ 

A$RENAME$FILE 

A$SEEK 

A$SPECIAL 

A$TRUNCATE 

A$WRITE 

CREATE$USER 


Table C-5. System Calls Used by the Application Loader 


NUCLEUS SYSTEM CALLS 

I/O SYSTEM SYSTEM CALLS 

EXTENDED I/O SYSTEM CALLS 
(if load job features 
are included) 

CATALOG$OBJECT 

A$ATTACH$FILE 

CREATE$IO$JOB 

CREATE$MAILBOX 

A$DELETE$CONNECTION 

S$ATTACH$FILE 

CREATE$SE(»IENT 

A$CLOSE 

S$DELETE$CONNECTION 

CREATE$TASK 

A$OPEN 


DELETE$JOB 

A$READ 


DELETE$MAILBOX 

A$SEEK 


DELETE $SEGMENT 

DELETE$TASK 

END$INIT$TASK 

GET$POOL$ATTRIB 

LOOKUP$OBJECT 

RECEIVE$MESSAGE 

SEND$MESSAGE 

SET$EXCEPTION$HANDLER 

SET$OS$EXTENSION 
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Table C-6. System Calls Used by the Human Interface 


NUCLEUS SYSTEM 

CALLS 

CATALOG$OBJECT 

get$type 

CREATE$MAILBOX 

LOOKUP$OBJECT 

CREATE$REGION 

RECEIVE$CONTROL 

CREATE $SEGMENT 

RECEIVE $MESSAGE 

CREATE$SEMAPHORE 

RECEIVE$UNITS 

CREATE$TASK 

SEND$CONTROL 

DELETE$JOB 

SEND$MESSAGE 

DELETE $MAILBOX 

SEND$UNITS 

DELETE$SEOIENT 

SET$EXCEPTION$HANDLER 

END$INIT$TASK 

SET$OS$EXTENSION 

GET$SIZE 


GET$TASK$TOKENS 

■ 1 

BASIC I/O SYSTEM CALLS 

j A$ATTACH$FILE 

A$READ 

A$DELETE$CONNECTION 

A$WRITE 

A$GET$CONNECTION$STATUS GET$TIME 

A$GET$EXTENSION$DATA 

SET$TIME 

A$OPEN 

1 

A$PHYSICAL$ATTACH$DEVICE 

EXTENDED I/O SYSTEM CALLS 

EXIT$IO$JOB 

S$OPEN 

S$ATTACH$FILE 

S$READ$MOVE 

S$CHANGE$ACCESS 

S$RENAME$FILE 

S$CREATE$FILE 

S$SEEK 

S $DELET E $CONNECTION 

S$SPECIAL 

S$DELETE$FILE 

S$TRUNCATE 

S$GET$CONNECTION$STATUS S$WRITE$MOVE 

S$GET$FILE$STATUS 


APPLICATION LOADER 

SYSTEM CALLS 

A$LOAD 


A$LOAD$IO$JOB 
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Underscored entries are primary references. 


204 driver 
206 driver 
208 driver 
215 driver 
218 driver 
220 driver 
254 driver 
2732 PROM 
51/4 inch 
8087 4-27, 
8253 6-8 

8259A 6-7 
957A/B 

monitor 

package 


9-32, 11-5 
9-34, 11-6 
9-36, 11-7 
9-37, 11-7 
9-37 

9-37, 11-7 
9-39, 11-9 
B-1 

diskette characteristics table 
6-1, 6-9 


4-4, 11-1 
4-28, 4-40 


9-32 


A$ATTACH$FILE 9-15, C-3 
A$CHANGE$ACCESS 9-17 
A$CL0SE 9-15, C-3 
A$CREATE$FILE 9-15, C-3 
A$DELETE$C0NNECTI0N 9-15, C-3 
A$DELETE$FILE 9-17, C-3 
A$GET$C0NNECTI0N$ STATUS 9-15, C-3 
A$GET$DIRECT0RY$ENTRY 9-17 
A$GET$EXTENSION$DATA 9-17, C-4 
A$GET$FILE$STATUS 9-15, C-3 
A$GET$PATH$C0MP0NENT 9-15 
A$L0AD$I0$J0B 10-2 
A$0PEN 9-15, C-3 

A$PHYSICAL$ATTACH$DEVICE 9-25, C-3 
A$READ 9-15, C-3 
A$RENAME$FILE 9-17, C-3 
A$SEEK 9-15, C-3 
A$SET$EXTENSION$DATA 9-17 
A$SPECIAL 9-15, C-3 
A$TRUNCATE 9-17, C-3 
A$WRITE 9-15, C-3 
absolute code 10-3, 13-10 

application job link procedures 4-8, 4-11, A-12 
Application Loader 4-35, 10-1 
entry point 4-37, 10-3 
system call usage C-3 
assembling the root job 4-38 
asynchronous job loading 10-3 
%ATTACH_DEVICE_TASK_PRIO macro 9-6 
%AUT0 macro 11-3 
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Basic I/O System 4-34, 9-1 
entry point 9-50 
features 9-18 
Initialization 9-50 
Interfaces 9-3, 9-5 
system call usage C-2 
B204.A86 11-5 

B206.A86 11-6 

B208.A86 11-7 

B215.A86 11-7 

B254.A86 11-9 

baud rate 7-3 
BCIC0.P86 11-11 
Bootstrap Loader 11-1 

driver configuration 11-4 
B204.A86 11-5 

B206.A86 11-6 

B208.A86 11-7 

B215.A86 11-7 

B254.A86 11-9 

BS1.A86 11-1 

BSl.CSD 11-10 

building the configuration file 4-22 
burning code into PROM 4-1, B-2 
burning the Nucleus into PROM B— 1 

clock_f requency 6-9 
command files 13-7 
comment character (;) 6-2 

common driver 9-25 
tables 9-27 

C0MM0N_DEV_INF0 structure 9-28 
compact model 3-2, 4-14, 4-27 
conq>onent configuration 6-6, 7-1 
condition code files 3-2 
configuration 

Application Loader 10-1 
Basic I/O System 9-1 
Bootstrap Loader 11-1 
Debugger 8-1 
environment 1-3 
Extended I/O System 12-1 
file 4-22 . 4-37, A-15, A-23 
Human Interface 13-1 
interface 9-3 
Nucleus 6-1 
overview 1-2, 2-1 
ROM/RAM-based system 5-1 
Teimilnal Handler 7-1 
types 1-5 
%C0NS0LE macro 11-2 
control-C semantics 7-8, 8-2 
count 6-9, 7-2 

CREATE$J0B system call 1-4, 4-25, 6-10 
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creating the configuration file 4-37, A-23 

creation of tasks 1-3 

CROOT.CSD 4-38, 5-2, A-23 

CROOT.LIB ‘5^39 

cylinders 11-8 

data segment allocation 4-27 
date/time interface 9-4 
DB.CSD 8-2 

Debugger 4-32, 4-34, 8-1, 13-5 
entry point 4-37, 8-3 
system call usage C-2 
default exception handler 4-32 
%DEFAULTFILE macro 11-3 
default memory pool 10-2 
DEFINE_DUIB structure 9-21 
DELETE $TASK system call 6-4 
demonstration system A-1 
describing I/O devices 9-20 
%DEV_INF0_BL0CK macro 12-4 
device granularity 9-23, 11-8 
%DEVICE macro 11-3 
devices 9-20 

name 9-21, 12-4 
number 9-23 
numbering 9-20 

device-information table 9-24, 9-27 
%DEVICE_TABLES macro 9-49 
device-unit information blocks 9-21 
cancel I/O procedure 9-24 
device granularity 9-23 
device information table pointer 9-24 
device name 9-21, 12-4 
device number 9-23 
device unit number 9-23 
file drivers 9-22 
finish I/O procedure 9-23 
flags 9-22 
functions 9-22 
high order device size 9-23 
initialize I/O procedure 9-23 
low ordere device size 9-23 
number of buffers 9-24 
priority 9-24 
queue I/O procedure 9-24 
unit information table pointer 9-24 
unit number 9-23 
update timeout 9-24 
device-unit number 9-20 , 9-23 
diskette preparation 4-9 
DTHCNF.A86 8-1 
DUIB 9-20, 9-21 
%DUMMY TIMER macro 9-19 
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E$BAD$SYNC$CONN 12-11 
E$NOT$CONFIGURED 9-15 
EDEVCF.A86 12-1 
EDEVCF.MAC 12-5 
edge triggering 6-8 
EEXCEP.LIT 3-3 

Eight-inch diskette characteristics table 9-31 

EIOS.CSD 12-10 

BIOS. EXT 3-3 

EJOBCF.A86 12-1 

ZENDJDEVjCONFIG macro 12-5 

%END_IO_JOB_CONFIG macro 12-10 

ZEND macro 11-4 

entry point 

Application Loader 4-37, 10-3 
Basic I/O System 4-37, 9-50 
Debugger 4-37, 8-3 
Extended I/O System 4-37, 12-11 
Human Interface 13-4 
Terminal Handler 4-37, 7-9 
EPIFC.LIB 4-14 
EPIFL.LIB 4-14 
errors 

nucleus and memory initialization 6-12 
root task 6-12 
STABLE. A86 12-1 

STABLE. MAC 12-3 

example system configuration A-1 
exception handler 4-25, 4-32, 4-39, 6-4, 12-8 
Extended I/O System 4-35, 12-1 . 13-6 
entry point 4-37, 12-11 
Initialization 12-11 
I/O jobs 12-6 
logical devices 12-4 
system calls 12-3, C-3 
external declaration 3-2 

F$ATTACH$DEV 9-22 
F$CL0SE 9-22 
F$DETACH$DEV 9-22 
F$0PEN 9-22 
F$READ 9-22 
F$SEEK 9-22 
F$SPECIAL 9-22 
F$WRITE 9-22 
file driver 9-5 

global data 9-5 
tables 9-7 

ZFILE_DRIVER_INFO macro 9-7 
FILE DRIVER_INF0 structure 9-7 
f lleTconnection interface 9-5 
first-level jobs 1-3 
fixed heads 11-8 
floating-point instructions 4-27 
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general device information 9-49 
general system layout 4-1, 5-2 
generating the root job 4-38, A-23 
GET$TASK$TOKENS system call 6-10 
global data 9-5 
granularity 9-23 
guidelines 

configuration files 4-11 
SUBMIT files 4-11 

H$COMMAND$NAME$MAX 13-3 
H$DEFAULT$DIR 13-2 
H$PREFIXES 13-3 
H$PR0G$DIRECT0RY 13-2 
H$SIGN$0N 13-3 
H$SYSTEM$DIRECTORY 13-2 
H$W0RK$DIRECT0RY 13-3 
HCONFG.P86 13-1 
HI.CSD 13-4 
HI. EXT 3-3 

HI.LIB 7-8, 8-2, 13-5 
high location of modules 4-2 
HPIFC.LIB 4-14 
HPIFL.LIB 4-14 
Human Interface 13-1 
commands 13-7 
entry point 4-37, 13-4 
requirements 13-5 
system call usage C-4 
volumes 13-7 


ICE-86 in-circuit emulator 4-40 
IDEVCF.A86 9-1 
IDEVCF.INC 9-3 
lEXCEP.LIT 3-3 


in-circuit emulator 4-39 


include files 3-2, 9-3 
initial system 1~3, 3-3 
Initialization 3-3, 9-50 
Intel-supplied device drivers 
byte bucket driver 9-48 
iSBC 204 driver 9-32 
iSBC 206 driver 9-34 
ISBC 208 driver 9-36 
iSBC 215 driver 9-37 
ISBX 218 driver 9-37 
iSBC 220 driver 9-37 
iSBC 254 driver 9-39 
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ISBX 270 terminal driver 9-46 
iSBC 86/1 2A on board USART 9-41 
ISBC 86 terminal driver 9-41 


interface libraries 4-13 
Interfaces 9-3, 9-5 
Interrupt 7-6, 9-28 
I/O devices 9-20 
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%IO_JOB macro 12-8. 13-6 
%IO_USER macro 12-7 
IOS_FILE_DRIVER structure 9-7 
lOS.CSD 9-49 
lOS.EXT 3-3 
IPIFC.LIB 4-14, 13-8 
IPIFL.LIB 4-14 
iSBC 204 driver 9-32, 11-5 
ISBC 206 driver 9-34, 11-6 
ISBC 208 driver 9-36, 11-7 
ISBC 215 driver 9-37, 11-7 
ISBC 218 driver 9—37 
ISBC 220 driver 9-37, 11-7 
ISBC 254 driver 9-39, 11-9 
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ISBC 957A/B package 4-28, 4-40 
ITABLE.A86 9-1 
I TABLE. INC 9-3 

%JOB macro 4-23, 4-34, 5-1, 13-6, A-15 
job preparation 3-1 
jobs 1-3 

language requirements 3-2 
large model 3-2, 4-14, 4-27 
layout of the system 4-1, 5-2 
LCONFG.P86 10-1 
level triggering 6-8 
LEXCEP.LIT 3-3 
LINK86 4-13 
linking 

application jobs 4-13 , A-12 
Application Loader lU-2 
Basic I/O System 9-49 
Bootstrap Loader 11-10 
Debugger 8-2, A-10 
Extended I/O System 12-10 
Human Interface 13-4 
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root job 4-38, A-23 
subsystems 4-8 
Terminal Handler 7-7 
load-time locatable (LTL) code 10-3 
LOADER. CSD 10-2 
LOADER. EXT 3-3 

loading the system 4-39, A-24 
LOC86 4-14, 5-4, B-I 
locating 

application jobs 4-14, 5-4, A-13 
Application Loader VS-2 
Basic I/O System 9-49 
Bootstrap Loader 11-10 
Debugger 8-2 , A-10 
Extended I/O System 12-10 
Human Interface 13-4 


Index-6 



INDEX (continued) 


locating (continued) 

Nucleus 6-11. A-6, B-1 
RAM-based systems 4-1 
ROM/RAM-based system 5-2, 5-4 
root job 4-38, A-23 
subsystems 4-8, 5-2, 5-4 
Terminal Handler 7-8 
logical devices 12-4 
logical name 12-4 
:$; 13-2 

:PROG; 13-2 
: SYSTEM: 13-2 

:WORK: 13-3 

low location of modules 4-2 
LPIFC.LIB 4-14, 13-8 
LPIFL.LIB 4-14 

* 

mailboxes 7-6 

ZMANUAL 11-3 

manual usage 1~5 

%MASTER_PIC macro 6-7 

MCONFG.A86 7-1 

medium model 3-2, 4-14, 4-27 

memory address space 4-28, 5-1, 

memory map 4-3, 5-3, A- 2 

memory pool 4-25, 12-8, 13-6 

metacharacter (%) 6-2 

minimizing memory address space 5-1 

module ordering 4-2 

MTH.CSD 7-7 

%MTH macro 7-3 

multiple Terminal Handlers 7-9 

named file driver 9-17 
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named files 9-6 
NDEVCF.A86 6-1, 6^6 
NDP 4-27, 6-9 
%NDP_SUPPORT macro 6-9 
NEXCEP.LIT 3-3 

non-file connection Interfaces 9-3 
%NO_ALLOCATE macro 9-19 
%NO_CREATE_FALSE macro 9-19 
XNOJTRDNCATE macro 9-19 
NTABLE.A86 6-1 
Nucleus 6-1 

component configuration 6-6 
default configuration 6-10 
INCLUDE files 3-2 
initialization errors 6-11 
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link and locate procedures 6-11, A-6, B-1 
maximal and minimal configuration 6-10 
programmable Interrupt controller configuration 6' 
root task errors 6-12 
system calls 6-5, C-1 
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NUCLUS.CSD 4-15, 6-11 
NUCLUS.EXT 3-3 
numbering devices 9-20 
%NUM_FILEJ)RIVERS macro 9-6 

object directory 4-25 
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on board USART 9—41 

optional subsystems 1-1 , 3-5, 4-8, 4-33 
order of modules 4-2, 4-38 
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Interface 9-3 
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physical file driver 9-15 
tables 9-8 
physical files 9-6 
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PIT 6-8, 7-5 
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Position Independent code (PIC) 6-7, 10-3 
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preparing 
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procedural overview 2-1 
programmable interrupt controller 6-7 
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RADEVJJNITJCNFO structure 9-30 
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REQ_FILE_DRIVER structure 9-7 
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ROM control 3-2 
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root job 3-3, 4-16, 4-38, A-12, A-23 

root task errors 6-12 
RPIFC.LIB 4-14 
RPIFL.LIB 4-14 
RQ$END$INIT$TASK 3-4 
RQINPUT 7-9 
RQOUTPUT 7-9 
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RQSYSEX 4-32 
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%SAB macro 4-28 , 5-1, 13-10, A-19 
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Series III development system 4-10, 13-7 
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Basic I/O System 9-49 
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macro parameters for 4-33 
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%SYSTEM values 4-36 
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system 
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ZSYSTEM_EXCEPTI0N_HANDLER macro 6-4 
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